Re[2]: ХОРОШЕ мнение о Delphi: С++MUST_DIE!!! - Священные войны

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

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

Y>>Вот пример совершенно не верного мнения человека как раз имеющего слабое представление о Delphi. Сбацать крутую, именно крутую GUI прогу на дельфи не чуть не легче чем на VC, а абсолютно также. При создании нормального, созданого заранее хорошим дизайнером UI придеться в равной мере писать свой код и что в Delphi и что в VC.

DG>Слово "крутая" надо было мне конечно взять в кавычки.

Ну а если брать в кавычки то и на VC ума не надо. Тоже самое рисование мышкой.....

Y>>И если взять думаю общий бюджет всех проектов в мире где используется VB или Delphi он будет не меньше тех проектов которые написанны на чистом C/C++

DG>Дык, это ты загнул, у Delphi очень низкая ниша — это написание малыми силами приложений типа Склад (работа с небольшими БД-шками). А вот такие приложения только у нас пишет каждый худо-бедный программист, а на западе норовят взять готовое, которое будет явно написано не на Delphi.

Откуда дровишки? Откуда информация о нише? Блин — вот тебе популярный пример — The Bat.

Y>>И еще о Дельфи — идея VCL сама по себе замечательная,

DG>Здесь я согласен.

Y>>язык Object Pascal — тоже имеет мало недостатков.

DG>Вот тут категорически не согласен.
DG>1. Это узкая разработка одной фирмы

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

DG>2. Сложность подключения сторонних библиотек (которые в большинстве написаны на C/C++)

И какие проблемы? Не вижу ни каких проблема....если имеется в виду скомпилированны библиотеки.

DG>3. Бедный синтаксис по сравнению с C++, и в то же время язык явно не дотягивает до Java/С#-а.

Это в чем то он бедный? Я знаю только два существенных отличия и то не считаю их критичными.....

DG>Единственный плюс, который я знаю, это скорость компиляции, здесь конечно Delphi впереди планеты всей.

P.S. Если будешь развернуто пытаться отвечать то лучше сразу переехать в "Прочее" или забить...

С Уважением Андрей.....

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

Y>Я например совершенно не вижу разницы например при написании какого нибуть сервиса для отслеживания обращения к диску например. И в куче других задач, в большенстве задач, разницы не будет.....

Y>Или вы считатет что человек который пишет проект используя MCF например знает априори меньше чем человек пришуший на чистом API?

Вообще говоря да. Вот полезны ли эти его знания это уже другой вопрос.

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

DG>>Слово "крутая" надо было мне конечно взять в кавычки.

Y>Ну а если брать в кавычки то и на VC ума не надо. Тоже самое рисование мышкой.....

Не совсем, в VC это все зделано через одно место, поэтому надо головой думать...

Y>Откуда дровишки? Откуда информация о нише?

По общению с народом, программившем на западе.

Y> Блин — вот тебе популярный пример — The Bat.

То-то я смотрю он у меня последнее время падает...

А если серьезно, то заметь — это опять СоцЛагерная разработка, а не западная...
А вот импортную я так сразу не назову... А нет знаю одну — "netcamels", от братьев наших по разуму — китайцев...

Y>>>язык Object Pascal — тоже имеет мало недостатков.

DG>>Вот тут категорически не согласен.
DG>>1. Это узкая разработка одной фирмы

Y> Нет не одной, компиляторов Pascal конечно меньше чем C но не на порядок. Но в прочем я не считаю это серьезным недостатком — язык уже на том уровне что если и фирма от него откажеться он будет продолжать жить...

Я где-то говорил про Паскаль? Он еще где-то используется?
Не передергивай, я говорил только про Object Pascal и компиляторов для object pascal-я два — Delphi & Kylix.

DG>>3. Бедный синтаксис по сравнению с C++, и в то же время язык явно не дотягивает до Java/С#-а.

Y> Это в чем то он бедный? Я знаю только два существенных отличия и то не считаю их критичными.....

Вот на эту тему я точно не хочу раздувать флейм...

DG>Это вызвано тем, что большинство Delphi-программистов (VBasic-программистов тоже) имеют очень низкую квалификацию.

Кстати, а может кто-то спрогнозировать перспективы такого подхода в отношении C#? Будут считать тех, кто пишет на шарпе "программистами низшего сорта" или нет?

DG>>а если приходит человек и говорит, я тут сбацал крутую GUI-программу на Delphi, то это говорит только о том, что человек умеет держать мышку...

A>Радикально неверное мнение!

Не, он все правильно сказал — перечитай еще раз. Из слов, что человек написал прогу на Delphi — НЕ СЛЕДУЕТ ПОЧТИ НИЧЕГО. Он может быть супер-программером, который просто больше любит Delphi, но чтобы выяснить это — придется приложить усилия...

Скажу вот что.

Во-первых, спор вошел не вту колею (впрочем, как всегда при споре "что лучше С++ или Дельфи"). Сам по себе этот спор некорректен и порочен ибо спорящие пользуются аргументами, искажающими дейсвительность.

Поясню. Есл человек действительно профессиона своего дела (а это понятие в большей мере определяется знанием преметной области, в которой он работает), то ему действительно, по большому счету, до лампочки на чем писАть. Конечно я не трогаю вопрос личных пристрастий — как говориться "на вскус и цвет...".

А суть вороса вот в чем. В большинстве книг для новичков по Дельфи с первых страниц, мы узнаем от авторитетных (для нас, новичков) авторов, что для программирование на Дельфи под Виндовс, Виндовса знать совсем не надо. Это и есть корень зла, несомого Дельфями. Это же парадокс! Далее, на протяжении всей книги мы лепим красивые формочки, надеваем на них рамочки и занимаемся написанием кода (по типу ShowMessage("Я крутой программист") в обработчиках событий. Такие книги ставят изучение инструмента (среды Дельфи, VCL) самоцелью. В редкой книге описывается решение мало-мальски приличной задачки.

Вывод: Дельфи начинающим программистам противопоказана, т.к. фомирует ложное ощущение знания. а это "знание" является очччень дешевым. И человека очень трудно потом от этого отучить. Отсюда и мнение (и мое тоже), что большинство, но, естессно, не все Дельфи-программисты, являются пользователями интересненького 2графического редактора" ( (с) по-моему IT

).

Хотя я знаю много примеров настоящих программистов[/i], работающих и любящих Дельфи, они выбрали Дельфи осознанно, после того, как выучили платформу (Виндовс), для которой они пишут и написав для нее множество программ на чистейшем WinApi. Про знание предметной области молчу — и так все понятно — на высшем уровне.

Подытожу: [b]начинать изучение программирования с Дельфи нельзя (опять-таки IMHO)

P.S. Имея ввиду "Дельфи" я подразумевал среду Borland C++ Builder, т.к. считаю, что человек, попробовавший С++ на Паскаль никогда не посмотрит (если его, конечно, не будут вынуждать обстоятельства).

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

DG>>>а если приходит человек и говорит, я тут сбацал крутую GUI-программу на Delphi, то это говорит только о том, что человек умеет держать мышку...

A>>Радикально неверное мнение!

IT>Не, он все правильно сказал — перечитай еще раз. Из слов, что человек написал прогу на Delphi — НЕ СЛЕДУЕТ ПОЧТИ НИЧЕГО. Он может быть супер-программером, который просто больше любит Delphi, но чтобы выяснить это — придется приложить усилия...

Там была формулировка — "крутую", я ее понял как "очень хорошую". Написание хорошого GUI — это очень весомы показатель, хороший GUI одинаково трудно создать и в Delphi и в VC.

С Уважением Андрей....

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

Y>И еще о Дельфи — идея VCL сама по себе замечательная, язык Object Pascal — тоже имеет мало недостатков.

Всё, нет больше Object Pascal'я, Борланд переименовала его в язык Delphi.

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

DG>>Это вызвано тем, что большинство Delphi-программистов (VBasic-программистов тоже) имеют очень низкую квалификацию.

IT>Кстати, а может кто-то спрогнозировать перспективы такого подхода в отношении C#? Будут считать тех, кто пишет на шарпе "программистами низшего сорта" или нет?

У "них", скорее всего — С#-программист в массе — средний (может быть чуть выше среднего) программист, т.к. у них для начинающий есть четкий продукт — VB.Net.

У "нас" почему-то VB.Net популярностью не пользуется, поэтому может получится по всякому, зависит куда все-таки пойдут начинающие программисты, на VB.Net или на C#, правда есть еще одна альтернатива — Delphi.Net (Borland должна что-нибудь такое родить)

Не берите в голову. Меня всегда удивляли люди, которые спрашивают не что я пишу, а на чем. IMHO какая разница на чем писать? Каждый пишет на том на чем удобнее. Я вот работал в одной конторке. Дык у них все продукты на Модуле2/Oberon2. И кстати отличные
языки программирования.

Зы. Главное чтобы работа нравилась и было куда развиваться.

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

DS>Вывод: Дельфи начинающим программистам противопоказана, т.к. фомирует ложное ощущение знания. а это "знание" является очччень дешевым. И человека очень трудно потом от этого отучить. Отсюда и мнение (и мое тоже), что большинство, но, естессно, не все Дельфи-программисты, являются пользователями интересненького 2графического редактора" ( (с) по-моему IT

).

Это не я. Это было монументальное произведение Влада — http://rsdn.ru/forum/?mid=3762

DS>P.S. Имея ввиду "Дельфи" я подразумевал среду Borland C++ Builder, т.к. считаю, что человек, попробовавший С++ на Паскаль никогда не посмотрит (если его, конечно, не будут вынуждать обстоятельства).

Ну очень спорное мнение... Не будем о себе ;) но лет 10 назад я общался с человеком, который очень неплохо программил и на асме (при мне успешно вирус ловил) и на С и на паскале.. И слова были его примерное такие, что "если надо, то надо, но ДЛЯ ДУШИ — конечно буду писать на паскале" ;)

DG>Если приходит человек и говорит, что написал GUI-программу на VC на WinApi (или даже на MFC), это значит что этот человек набрался хоть каких-то знаний о Windows,
DG>а если приходит человек и говорит, я тут сбацал крутую GUI-программу на Delphi, то это говорит только о том, что человек умеет держать мышку...

Закончили полугодовой проект, где вся команда писала на C++ Builder... У меня, например, панель компонентов все полгода вообще была отключена за ненадобностью — была рабоа с БД, импорт-экспорт инфы в разные форматы, etc, т.е. компоненты визуальные практически не использовались. Добросовестно топтал клаву...

Так что насчет мыши ты погорячился...

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

Y>Я например совершенно не вижу разницы например при написании какого нибуть сервиса для отслеживания обращения к диску например. И в куче других задач, в большенстве задач, разницы не будет.....
Delphi всетаки предназначен для написания мелких и средних систем для работы в основном с БД. Соответственно на производстве он используется по назначению и написание сервисов отслеживающих чего-то там в большей степени исключение чем правило. А люди которые пишут клиентов на Дельфях в 90% случаях ламера.

Y>Или вы считатет что человек который пишет проект используя MCF например знает априори меньше чем человек пришуший на чистом API?

В определенных вещах ДА! Я имею ввиду конечно же не всех. Просто человек никогда не писавший на API, а только на MFC знает о "окнах" значительно меньше, чем API программера.

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

Y>Там была формулировка — "крутую", я ее понял как "очень хорошую". Написание хорошого GUI — это очень весомы показатель, хороший GUI одинаково трудно создать и в Delphi и в VC.

Ну и совсем не правда!

На VC сложнее. Хотел бы я посмотреть на реализацию комонента типа какого-то сложного контрола в исполнении среднестатистического дэльфиста на VC.

Эти вещи не находятся в такой банальной зависимости. Зарплата определяется спросом, а уж потом классом.

Y>И если взять думаю общий бюджет всех проектов в мире где используется VB или Delphi он будет не меньше тех проектов которые написанны на чистом C/C++

Ну!!!

А бактерии по биомассе превосходят все человечество в 1000чи раз. Так что теперь, они умнее нас?

Y>И еще о Дельфи — идея VCL сама по себе замечательная, язык Object Pascal — тоже имеет мало недостатков.

И чем мне интерестно VCL круче MFC?

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

DG>Если приходит человек и говорит, что написал GUI-программу на VC на WinApi (или даже на MFC), это значит что этот человек набрался хоть каких-то знаний о Windows,
DG>а если приходит человек и говорит, я тут сбацал крутую GUI-программу на Delphi, то это говорит только о том, что человек умеет держать мышку...

В принципе со всем вышесказанным согласен:
наверно, поэтому и пытасюь выбросить из головы Foxpro,VFP и прочую лабудень,
хотя достаточно обидно, что в свое время потратил много времени на освоение данных средств программирования,
стал действительно (как мне кажется) классно писать программы, написал кучу всяких примочек, библиотек,несколько
коммерческих продуктов — а теперь вижу, что перспективы нет.

Счас женился, куча каких-то мелких проблем. Ночи уже не те. :-\ (Ведь раньше то мог вдоволь начитаться, помучить свой комп ) времени ни на что не хватает.

И вот теперь оказывается, что практически я полный ноль. Начинаю изучать с нуля WINAPI, принципы работы с базами данных, Ц++......

ЗЫ: Ваше мнение интересует по данному поводу

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

DG>Здравствуйте Igor Trofimov, Вы писали:

DG>>>Это вызвано тем, что большинство Delphi-программистов (VBasic-программистов тоже) имеют очень низкую квалификацию.

DG>У "них", скорее всего — С#-программист в массе — средний (может быть чуть выше среднего) программист, т.к. у них для начинающий есть четкий продукт — VB.Net.
Кстати, интересно — когда у нас оформится устойчивый спрос на С#-программистов и весь спектр дотНЕТа?
DG>У "нас" почему-то VB.Net популярностью не пользуется, поэтому может получится по всякому, зависит куда все-таки пойдут начинающие программисты, на VB.Net или на C#, правда есть еще одна альтернатива — Delphi.Net (Borland должна что-нибудь такое родить)

Весьма прелюбопытное по архитектуре зрелище должно быть будет

Особенно учитывая то, что ребята из Бормана, похоже, как и МС, без серъезных огрехов работать все-таки не могут

DM>Ну и совсем не правда! :) На VC сложнее. Хотел бы я посмотреть на реализацию комонента типа какого-то сложного контрола в исполнении среднестатистического дэльфиста на VC. :super:

Да, это точно.. Но — не кажется ли присутствующим, что здесь имеется довольно парадоксальная ситуация... Настоящим профи считается тот, кто использует фактически менее удобную систему? Может, стоит сделать жутко неудобную систему, в которой helloWorld занимает пару сотен строк, но уж если человек НА ЭТОМ пишет проги — значит точно профи ;))) Нет, тут, как мне кажется, явно что-то не так, как хотелось бы...

muh>Кстати, интересно — когда у нас оформится устойчивый спрос на С#-программистов и весь спектр дотНЕТа?

Думаю, через годик... До релиза — никто и не думал, кроме энтузиастов о Дотнете, а вот сейчас... Имею информацию, что многие крупные конторы типа Vestedev (в Москве) присматриваются к нему...

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

A>Закончили полугодовой проект, где вся команда писала на C++ Builder... У меня, например, панель компонентов все полгода вообще была отключена за ненадобностью — была рабоа с БД, импорт-экспорт инфы в разные форматы, etc, т.е. компоненты визуальные практически не использовались. Добросовестно топтал клаву...

A>Так что насчет мыши ты погорячился...

Ну и как ты сам считаешь это типичный проект или исключение?

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

IT>Да, это точно.. Но — не кажется ли присутствующим, что здесь имеется довольно парадоксальная ситуация... Настоящим профи считается тот, кто использует фактически менее удобную систему? Может, стоит сделать жутко неудобную систему, в которой helloWorld занимает пару сотен строк, но уж если человек НА ЭТОМ пишет проги — значит точно профи ;))) Нет, тут, как мне кажется, явно что-то не так, как хотелось бы...

Вот-вот :-) Представим, что у нас есть рельсина и от нее надо куско отрезать. И есть у нас три интструмента — кусок полотна, болгарка и автоген. И кого будем профи считать?

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

DM>>Ну и совсем не правда!

IT>Да, это точно.. Но — не кажется ли присутствующим, что здесь имеется довольно парадоксальная ситуация... Настоящим профи считается тот, кто использует фактически менее удобную систему? Может, стоит сделать жутко неудобную систему, в которой helloWorld занимает пару сотен строк, но уж если человек НА ЭТОМ пишет проги — значит точно профи

)) Нет, тут, как мне кажется, явно что-то не так, как хотелось бы...

Я бы сформулировал бы по другому: "если уж человек на этом написал программу, значит он профи".
А вот почему он выбрал именно это средство — это уже отдельный разговор, разговор о том, в выборе средств — данный человек профи или нет.

Небольшой пример:
Если человек, смог написать на Visual Basic-е драйвер для видеокарты, значит данный человек профи в Visual Basic-е и в написании драйверов.
А если другой человек смог написать WebService на ассемблере, значит данный человек профи в ассемблере и в WebService-ах.

Но оба этих человека — полный профаны в выборе наиболее адекватных средств программирования под конкретные задачи.

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

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

A>>Закончили полугодовой проект, где вся команда писала на C++ Builder... У меня, например, панель компонентов все полгода вообще была отключена за ненадобностью — была рабоа с БД, импорт-экспорт инфы в разные форматы, etc, т.е. компоненты визуальные практически не использовались. Добросовестно топтал клаву... :shuffle:
A>>Так что насчет мыши ты погорячился... :)

A>Ну и как ты сам считаешь это типичный проект или исключение?

Конечно, исключение.
Притом заметь, что это таки C++. IMHO, у Buildera гораздо лучше перспектвка, чем у Delphi. Чего спорить, "бацанье" интерфейса у Борланда лучше чем у VC (все версии).

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

SC>Вот-вот

Представим, что у нас есть рельсина и от нее надо куско отрезать. И есть у нас три интструмента — кусок полотна, болгарка и автоген. И кого будем профи считать?

Если вызовем трех людей, дадим одному полотно, второму болгарку, а третьему автоген — и они все в троем разрежут рельс, то профи скорее всего первый.

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

Здравствуйте Аноним, Вы писали:

А>Притом заметь, что это таки C++. IMHO, у Buildera гораздо лучше перспектвка, чем у Delphi. Чего спорить, "бацанье" интерфейса у Борланда лучше чем у VC (все версии).

Конечно. Портит его только то что VCL написана не на C++.
В результате он вместе со всеми достонствами Delphi и С++ одновременно
получил и все их недостатки. Кроме того Borland его не считает основным
своим продуктом.

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

DG>Здравствуйте Igor Trofimov, Вы писали:

DM>>>Ну и совсем не правда!

IT>>Да, это точно.. Но — не кажется ли присутствующим, что здесь имеется довольно парадоксальная ситуация... Настоящим профи считается тот, кто использует фактически менее удобную систему? Может, стоит сделать жутко неудобную систему, в которой helloWorld занимает пару сотен строк, но уж если человек НА ЭТОМ пишет проги — значит точно профи

)) Нет, тут, как мне кажется, явно что-то не так, как хотелось бы...

DG>Я бы сформулировал бы по другому: "если уж человек на этом написал программу, значит он профи".
DG>А вот почему он выбрал именно это средство — это уже отдельный разговор, разговор о том, в выборе средств — данный человек профи или нет.

DG>Небольшой пример:
DG>Если человек, смог написать на Visual Basic-е драйвер для видеокарты, значит данный человек профи в Visual Basic-е и в написании драйверов.
DG>А если другой человек смог написать WebService на ассемблере, значит данный человек профи в ассемблере и в WebService-ах.

DG>Но оба этих человека — полный профаны в выборе наиболее адекватных средств программирования под конкретные задачи.

А если разработчик выбрал Delphi — значит он не профи ? (даже если это оптимальное средство для данной предметной области). Это следствие вытекает из ваших рассуждений.

Профессионализм определяется умением решать определенный вид задач быстро и качественно. В этом плане Delphi (и VB) отлично подходят для написания корпоративного софта, C++ для написания драйверов и системных служб и т.п.

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

DG>>Но оба этих человека — полный профаны в выборе наиболее адекватных средств программирования под конкретные задачи.

SMS>А если разработчик выбрал Delphi — значит он не профи ? (даже если это оптимальное средство для данной предметной области).

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

SMS>Это следствие вытекает из ваших рассуждений.

SMS>Профессионализм определяется умением решать определенный вид задач быстро и качественно. В этом плане Delphi (и VB) отлично подходят для написания корпоративного софта,

Delphi и VB — идеально подходят только для быстрого накидывания интерфейса, Delphi — также подходит для быстрого накидывания интерфейса для работы с БД.

Серьезные вещи на Delphi — писать не удобно.
минусы:
1. Это наличие своего языка, который не совместим с С, поэтому все библиотеки (которые в большинстве C-шные) надо руками (что в конечном итоге лишнии время и лишние деньги) конвертить в Dephi.
2. Слабая (вернее полное отсутствие) поддержка какой-либо идеологии данные/представление
3. Малая доля общего рынка, и совсем ничтожная доля рынка серьзных продуктов, отсюда отсутствие каких-либо уже существующих наработок на рынке и "сырость" стандартных средсв.
4. Серьезное оставание от Windows "mainstream"-а.
5. Слабая интегрированность в Windows "mainstream"

Вот это очень серьезные стратегические минусы, которые надо принимать во внимание, при выборе в качестве разработки Delphi.

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

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

DG>Вдогонку...

S>>>По-вашему, чем вызвано такое негативное отношение?

DG>Если приходит человек и говорит, что написал GUI-программу на VC на WinApi (или даже на MFC), это значит что этот человек набрался хоть каких-то знаний о Windows,
DG>а если приходит человек и говорит, я тут сбацал крутую GUI-программу на Delphi, то это говорит только о том, что человек умеет держать мышку...
По-моему программа не из одного GUI состоит. Если человек написал программу с "крутым" GUI с меньшими усилиями, значит у него остается больше сил и времени для реализации прикладной задачи, чем утого, кто написал программу с "крутым" GUI но на голом API. А следовательно с прикладной точки зрения, программа первого должна быть "круче", чем у второго.

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

DG>Я опять же повторюсь, что разговор шел об усредненном человека, который пользуется Delphi, я не говорил, что среди Delphi-стов нет профи.
Я уже заметил, что в таких спорах сводящихся к тому, что 90 процентов делфистов мягко говоря не очень хорошие программисты, обязательно найдется какой нить профи (без кавычек), который будет все воспринимать на свой счет!

DG>Delphi и VB — идеально подходят только для быстрого накидывания интерфейса, Delphi — также подходит для быстрого накидывания интерфейса для работы с БД.
Совершенно точно!!! В теории даже существует порог для размеров систем, написанных в этих средах. Если не ошибаюсь, то команда не может превышать 50 человек (не надо кидать в меня ни чем тяжелым). При выходе за эти рамки конечно же ничего страшного не произойдет, но затраты на разработку начнут резко рости и работа на Делфи станет не выгодной. Я думаю каждый кто писал более менее серьезный проект на Делфи знает, как глючен он становится при росте проекта.

DG>Серьезные вещи на Delphi — писать не удобно.

Некоторые вещи писать ваще нельзя.

DG>минусы:
DG>3. Малая доля общего рынка, и совсем ничтожная доля рынка серьзных продуктов, отсюда отсутствие каких-либо уже существующих наработок на рынке и "сырость" стандартных средсв.
Ну зачем же так мрачно? На своей нише Делфи вне конкуренции(рынок РАД систем). Это замечу мое личное мнение вытекающее из опыта.

DG>Вот это очень серьезные стратегические минусы, которые надо принимать во внимание, при выборе в качестве разработки Delphi.
Кто не без греха? :)) Но это все не о том. У каждой среды разработки есть свой рынок и т.п. Но суть в том, что среды типа Делфи плодят программистов не обладающих системностью познания в области в которой работают. Я сразу же оговорюсь, что конечно же это может и никогда и не пригодится (писать на API), но мы же ходим в школу по крайней мере до 10го класса даже если вы потом грузчиками будете. Вопрос именно в этом. Смешно видеть профессионала, который не знает как написан VCL, на котором он творит чудеса. :(

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

D>И вот теперь оказывается, что практически я полный ноль. Начинаю изучать с нуля WINAPI, принципы работы с базами данных, Ц++......

D>ЗЫ: Ваше мнение интересует по данному поводу

Мастерство не пропьёшь

Если у тебя мозги программиста, то ты быстро наберёшь форму. Если в Фоксе были элементы ООП, то с этим тоже не будет проблем, либо можно почитать какие-нибудь толковые книжки, у меня в своё время порядок в голове навёл Буч.

А C++ начинай учить с адресной арифметики, т.е. с C

Всё остальное только лишь другой синтаксис.

На WinAPI забей, его нельзя изучить, лучше научится нормально работать с MSDN. Хотя понимать основы работы Windows необходимо. Здесь лучший помошник — Рихтер.

Нужны ещё основы COM, точнее даже не самого COM, а компонентного программирования. Без него сейчас никуда.

Ну и самое главное — желание.

Удачи.

Здравствуйте:

Тут прозвучало множество неверных высказываний:

— Большинство испольэзует С++.

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

— Дельфи плохо подходит для больших проектов

Скорее наоборот, Дельфи прекрасно подходит для больших проектов, т. к. Object Pascal -- язык более строгий и простой.
Легче не допускать ощибки и отлавливать возникшие. Визуальэное проектирование тут уходит на второй план.

— Object Pascal несовместим с С, поэтому приходится жутко переделывать интерфейс к библиотекам

Вы же прекрасно знаете что эта переделка сводится к замене синтаксиса С на синтаксис Паскаля. На "бинарном уровне" ничего делать не надо, все совместимо.

— Человек, пишущий на MFC учится большему, чем человек, пишущий на Дельфи

MFC можно считать образцом того, как не надо писать библиотеки на C++. И чему же человек учится? Плохому стилю программирования на C++

— Дельфи выпускается одной компанией, а С++ стандартизирован

На чем программируете под Windows на C++? На MS Visual С++. MS не следует стандарту, одно не реализует, другое реализует криво, третье по своему. Достаточно зайти в раздел по C++ данного форума и почитать темы о С++ в VS, чтобы с этим согласится.

— Язык Дельфи не дотягивает ни до С++, ни до Net.

Вы просто не знаете язык Дельфи.
А в Net многое откровенно слизано с Дельфи.

Одним из главным аргументов в польэу Net, служит быстрота и ПРОСТОТА разработки на нем. Эти же аргументы приводят в качестве недостатком Дельфи. Остается только удивляться такой ненормальной логике.
Дельфи дает простоту и скорость, причем сделано это уже давно, причем сочетается с быстротой вып-я программы, т. к. Дельфи делает настоящие экзешки. И вот теперь, через 6 лет, MS преподносит свое "открытие", которое даже не не компилирует в exe и требует огромных системных ресурсов.

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

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

S>>Часто приходится слышать мнение, что разработчики, использующие delphi -
S>>ваще не программисты, а так... детишки неразумные.
S>>Ясно, что у нее (как и у каждого ср-ва разработки) есть свои минусы,
S>>но и плюсы тоже имеются. Я, например, юзаю с равной интенсивностью и
S>>delphi, и vc++, и MASM. И что, об этом лучше никому не говорить?
S>>По-вашему, чем вызвано такое негативное отношение?

Целиком и полностью согласен с Вами. Профессионализм определяется не тем, на чем ты пишешь — а тем, как ты пишешь, насколько хорошо ты разбираешься в своей сфере деятельности. Почитаешь сообщения и можно подумать, что самый самый профессионал это тот, который использует непременно asm. Я думаю, что о вашем профессионализме по большому счету будут судить пользователи ваших программ. Им абсолютно без разницы на чем напрсана ваша программа — на asm, Delphi или VС++. Для них главное, чтобы ваша программа была как минимум работоспособной, надежной и удобной в использовании. Ну и было бы совсем хорошо, если бы вы программу для вашего заказчика могли сделать быстро.
В дополнение к сказанному. Начисто отвергать одни инструменты для программирования и безоговорочно принимать другие — это крайности, которы приводят к ограниченности человека. А это не есть хорошо для него, как для профессионала, если он себя таковым считает.
И еще. Ни Delphi, ни VB ни другое средство визуального программирования совершенно не подходят для начинающих, ибо все программирование для них просто закрывается и написание программ сводится к "рисованию" простеньких интерфейсов. А умение аналитически мыслить, умение составлять алгоритмы и т.д. само по себе никогда не прийдет. И в этом смысле люди, пропагандирующие подобны средства для новичков, оказывают им медвежью услугу как будующим профессионалам. И поскольку кажущаяся легкость работы на Delphi или на VB и их доступность привлекают именно новичков, то потом уже не удивляешься когда слышишь не очень лестные мнения о программистах, работающих на Delphi. Хотя как кто-то ухе говорил — нельзя стричь всех под одну гребенку.

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

По болшОму счету я стобой почти огласен. Но я же предупреждал — суть спора уходит всторону. Я считаю, что уродливость/красоту Дельфи нужно обсуждать только в контексте "начинать ли путь в программировании с Дельфи". Профессионалам и так все понятно. И судя по всему это все прекрасно понимают, а спорят не понятно очем

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

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

S>>Часто приходится слышать мнение, что разработчики, использующие delphi -
S>>ваще не программисты, а так... детишки неразумные.
S>>Ясно, что у нее (как и у каждого ср-ва разработки) есть свои минусы,
S>>но и плюсы тоже имеются. Я, например, юзаю с равной интенсивностью и
S>>delphi, и vc++, и MASM. И что, об этом лучше никому не говорить?
S>>По-вашему, чем вызвано такое негативное отношение?

Тут еще существует проблема разных методологий и стилей разработки.

Проект на Дельфи это КАК ПРАВИЛО пилотная разработка или развитие прототипа реализованого на нем же. Тут используеться в основном экстрим программинг. Я ничего не имею против этой методологии, наоборот очень часто ее применяю. Но есть у этой методологии определенные минусы.
В рамках данной методологии, необходимо часто проводить реструктуризацию, что при существовании конечного продукта реализованного на Дельфи сложно с психологической точки зрения — зачем, все и так работает.

Проект на С++ КАК ПРАВИЛО продукт этапной итерации основаный на независимых от среды разработки протопипах.(я обычно просто рисую пользовательский интерфейс и описываю как он должен работать — "бумажный" прототип) Тут могут одинаково хорошо применяться различные методологии. Структуризацию и реструктуризацию приходиться проводить с самого начала т.к. этого требует этап проектирования. Реструктуризация проходит без проблем(при грамотном проектировании).

Напремер. С чего начинает програмист Дельфи — КАК ПРАВИЛО с разработки интерфейса. А с чего начинает программист на С++ — КАК ПРАВИЛО с разработки структуры классов и модулей.

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

По моему личному мнению Дельфи подходит для написания небольших проектов, не требующих длительного развития (эволюционирования). Тогда можно использовать его стиль и метод разработки. Особенно он хорош для написания рабочих прототипов.
А вот разрабатывать "долгосрочные" проекты я бы не стал. На премере The Bat :up: можно видеть что кроме улучшения интерфейса и добавление функций, структурные изменения вряд ли будут иметь место в следующих версиях. Хотя я могу ошибаться. :))

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

DG>Здравствуйте Igor Trofimov, Вы писали:

DG>>>Это вызвано тем, что большинство Delphi-программистов (VBasic-программистов тоже) имеют очень низкую квалификацию.

IT>>Кстати, а может кто-то спрогнозировать перспективы такого подхода в отношении C#? Будут считать тех, кто пишет на шарпе "программистами низшего сорта" или нет?

DG>У "них", скорее всего — С#-программист в массе — средний (может быть чуть выше среднего) программист, т.к. у них для начинающий есть четкий продукт — VB.Net.

Ну незнаю средний или нет, но я со следующей недели перебираюсь в контору, которая полностью перешла под .NET и пишут все на C#, и их система уже находится в коммерческой эксплуатации.

Пора завязывать с этим низким уровнем (MFC,ATL,COM,WINAPI) это все скоро начнет потихоньку отмирать.

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

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

Как известно по закону Мура производительность компютеров кождые 10 лет увеличивается в 30 раз. Как следствие этого, сложность и объемы ПО, естейственно тоже увеличиваются в 30 раз. Чтобы писать такое ПО ничего не остается как переходить на более высокоуровневые средства разработки.

Если лет через 20 производительность компов еще вырастет в 1000 раз, то уже не останется такого уровня как есть в WinAPI,MFC, Assembler. Будут инструменты гораздо более высокого уровня, на которых GUI будет собираться быстрее и проще чем на Delphi.
Да и вобще GUI это дело второстепенное.
Проблема Delphi не в том, что она позволяет что-то быстро и просто сделать, а в ограниченности возможностей и негибкости, если копнуть поглубже.
На C# и в .NET дела обстоят гораздо лучше, хоть дизайнер WinForms похож на Дельфозный но это гораздо круче чем Delphi.

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

EB>- Человек, пишущий на MFC учится большему, чем человек, пишущий на Дельфи

EB>MFC можно считать образцом того, как не надо писать библиотеки на C++. И чему же человек учится? Плохому стилю программирования на C++

Такой вопрос: Я вообще на VC никогда не писал, а всю жизнь был сторонником Паскаля, Дельфи, а теперь люблю еще и Си++Билдер. Поэтому хотел узнать, что есть МФК, в чем его отличие от ВЦЛ и почему у тебя такое мнение о нем

EB>- Дельфи выпускается одной компанией, а С++ стандартизирован
EB>На чем программируете под Windows на C++? На MS Visual С++. MS не следует стандарту, одно не реализует, другое реализует криво, третье по своему. Достаточно зайти в раздел по C++ данного форума и почитать темы о С++ в VS, чтобы с этим согласится.

Вот это супер!

EB>- Язык Дельфи не дотягивает ни до С++, ни до Net.
EB>Вы просто не знаете язык Дельфи.
EB>А в Net многое откровенно слизано с Дельфи.
[skip]

Воплне доходчиво объяснил, спасибо! Очень часто такого рода HolyWars втягивали и меня, но не сразу в голову приходили достойные аргументы.

Пока! С уважением, Валентин Овчаренко.

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

EB>>MFC можно считать образцом того, как не надо писать библиотеки на C++. И чему же человек учится? Плохому стилю программирования на C++

R>Такой вопрос: Я вообще на VC никогда не писал, а всю жизнь был сторонником Паскаля, Дельфи, а теперь люблю еще и Си++Билдер. Поэтому хотел узнать, что есть МФК, в чем его отличие от ВЦЛ и почему у тебя такое мнение о нем

MFC — Microsofy Foundation Library — основная библиотека в VC.
Насчет мнения: взять хотя бы повальное использование макросов и открытых полей данных. Страуструп много говорит, почему в C++ использование и того, и другого -- очень плохой стиль.

Здравствуйте :

Виноват

EB>MFC — Microsofy Foundation Library — основная библиотека в VC.
MFC — Microsofy Foundation Classes.

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

IT>Мастерство не пропьёшь

IT>Если у тебя мозги программиста, то ты быстро наберёшь форму. Если в Фоксе были элементы ООП, то с этим тоже не будет проблем, либо можно почитать какие-нибудь толковые книжки, у меня в своё время порядок в голове навёл Буч.

IT>А C++ начинай учить с адресной арифметики, т.е. с C

Всё остальное только лишь другой синтаксис.

IT>На WinAPI забей, его нельзя изучить, лучше научится нормально работать с MSDN. Хотя понимать основы работы Windows необходимо. Здесь лучший помошник — Рихтер.

IT>Нужны ещё основы COM, точнее даже не самого COM, а компонентного программирования. Без него сейчас никуда.

IT>Ну и самое главное — желание.

IT>Удачи.

Спасибо за поддержку, ваш сайт — пока лучший помощник в приобретении знаний и практики.

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

EB>А в Net многое откровенно слизано с Дельфи.

Не слизано а куплено

Бывший главный идеолог Delphi теперь работает
в Microsoft и занимается там .net и с#

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

D>Счас женился, куча каких-то мелких проблем. Ночи уже не те.

(Ведь раньше то мог вдоволь начитаться, помучить свой комп ) времени ни на что не хватает.

D>И вот теперь оказывается, что практически я полный ноль. Начинаю изучать с нуля WINAPI, принципы работы с базами данных, Ц++......

D>ЗЫ: Ваше мнение интересует по данному поводу

Очень хорошо тебя понимаю

Когда-то оказался в таком же положении

Ничего, расставил приоритеты, наверстываю упущенное

Главное — не браться за все подряд, заниматься 1 темой одновременно (max 2).

На твоем месте я бы изучал

С++ (MSVC || Builder);
БД (если не работал с ними) — общая теория, SQL, потом приложение к какому-нибудь серверу;
основы проектирования — Буч etc., UML и IDEF0;
можно попробавать себя в веб — HTML, серверные скрипты (PHP, ASP — без разницы), веб-интерфейсы к БД

Остально добавить по вкусу

Много всего интересного сказали и я не могу остаться в стороне.

Расскажу одну правдивую историю. несколько лет пишу на VC++ и уже неплохо с ней знаком. А тут вдруг интересно стало — кто такая дельфи? Паскать 7.0 я когда-то изучал, поставил себе Delphi 6 и... сразу создал рабочее приложение.

Т.е. вобще без книжек безо всего — это говорит о простоте дельфи.

Потом решил прилепить к готовой программе на VC++ дельфячью DLL. Все в принципе без проблем собралось и заработало (главное не забыть cdecl

). НО! Поскольку у меня уже были аналогичные длл написаные на сях я, естессно, сравнил их размер. 24 Кб сей против 300 с чем-то у дельфей. Вывод: за простоту надо платить!

После прочтения книжки про дельфи нашел одну интересную хозму (вот C++ программеры посмеются). Вызов чисто вируальных методов класса отслеживается не на этапе компиляции, а на этапе выполнения.

Вобще, надо сказать, очень убогий оптимизатор у борланда. Что у дельфей, что у бильдера. Это не мое личное мнение, это все эксперементально подтверждено.

А вобще работодатели дельфю любят (это мое мнение). Т.к. дельфи программист раз-два и собрал программу. Неважно, что она УЖЕ весит больше мегабайта. Неважно, что постоянно вылезают глюки. Не важно, что для того чтобы работать с базами данных надо устанавливать дельфю на целевой компьютер (сам с этим сталкивался, когда мне предложили поюзать дельфовую прогу юзающую BDE). Зато быстро!

Итак, я считаю — Visual C++ ONLY & FOREVER. Но если знаешь дельфи, сказать об этом никогда не вредно. Вобще, чем больше знаешь, тем лучше. думаю работодатели это оценят. :-
S>Часто приходится слышать мнение, что разработчики, использующие delphi -
S>ваще не программисты, а так... детишки неразумные.
S>Ясно, что у нее (как и у каждого ср-ва разработки) есть свои минусы,
S>но и плюсы тоже имеются. Я, например, юзаю с равной интенсивностью и
S>delphi, и vc++, и MASM. И что, об этом лучше никому не говорить?
S>По-вашему, чем вызвано такое негативное отношение?

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

Y>Мое мнение таково — единственной оценкой крутости проффесионального програмиста может быть только количесто денег которое он зарабатывает....
Y>И если взять думаю общий бюджет всех проектов в мире где используется VB или Delphi он будет не меньше тех проектов которые написанны на чистом C/C++

Ну да: на стороне VB значительный перевес!

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

Y>>И если взять думаю общий бюджет всех проектов в мире где используется VB или Delphi он будет не меньше тех проектов которые написанны на чистом C/C++

DG>Дык, это ты загнул, у Delphi очень низкая ниша — это написание малыми силами приложений типа Склад (работа с небольшими БД-шками). А вот такие приложения только у нас пишет каждый худо-бедный программист, а на западе норовят взять готовое, которое будет явно написано не на Delphi.

Или написать свое, но на VB.

Я не против Delphi, просто у меня такое мнение. И не один я его поддерживаю...

Y>>язык Object Pascal — тоже имеет мало недостатков.

DG>Вот тут категорически не согласен.
DG>1. Это узкая разработка одной фирмы
DG>2. Сложность подключения сторонних библиотек (которые в большинстве написаны на C/C++)
DG>3. Бедный синтаксис по сравнению с C++, и в то же время язык явно не дотягивает до Java/С#-а.

4. Сложность аналогичных конструкций по сравнению с C++ (по-моему: аргументировать уже не смогу, пожалуй, давно с Delphi не работал...)

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

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

DG>>Если приходит человек и говорит, что написал GUI-программу на VC на WinApi (или даже на MFC), это значит что этот человек набрался хоть каких-то знаний о Windows,
DG>>а если приходит человек и говорит, я тут сбацал крутую GUI-программу на Delphi, то это говорит только о том, что человек умеет держать мышку...

D>В принципе со всем вышесказанным согласен:
D>наверно, поэтому и пытасюь выбросить из головы Foxpro,VFP и прочую лабудень,
D>хотя достаточно обидно, что в свое время потратил много времени на освоение данных средств программирования,
D>стал действительно (как мне кажется) классно писать программы, написал кучу всяких примочек, библиотек,несколько
D>коммерческих продуктов — а теперь вижу, что перспективы нет.

D>Счас женился, куча каких-то мелких проблем. Ночи уже не те. :-\ (Ведь раньше то мог вдоволь начитаться, помучить свой комп ) времени ни на что не хватает.

D>И вот теперь оказывается, что практически я полный ноль. Начинаю изучать с нуля WINAPI, принципы работы с базами данных, Ц++......

D>ЗЫ: Ваше мнение интересует по данному поводу

Начинать с нуля WinAPI, принципы работы с БД, C++ и "прочую лабудень" по-моему не стоит. WinAPI во-первых чрезмерно широк и имеет ряд довольно узких специализаций, а во-вторых по слухам предполагается быть упраздненным. Принципы работы с БД в VFP и других системах не особо отличаются. C++ — это вообще отдельная тема, тут я не могу ничего сказать.

Тут вот меня просили "помочь изучить C++". Проект для изучения был о-очень оригинальный: БД на Postgress (так, кажется, пишется) с клиентами на Telnet или что-то такое — я точно не вник. Я попытался объяснить, что подобный проект проще, эффективнее, рациональнее и все такое, делать на Visual Basic, но... Наверное мне еще стоит поучиться риторике. Не знаю как вы, а я, например, просто в шоке от кода ADO под C++. Вот в VB это просто очаровательно! Но в C++ — нет, увольте!

Это, разумеется, мое скромное мнение, именуемое также ИМХО или IMHO — как кому больше нравится...

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

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

DM>>В определенных вещах ДА! Я имею ввиду конечно же не всех. Просто человек никогда не писавший на API, а только на MFC знает о "окнах" значительно меньше, чем API программера.

SC>Спорный вопрос. Как всегда, тут вопрос упирается в то, чем человек занимался и чем будет заниматься. Неразумно городить API там где, можно использовать MFC (ATL, VCL, etc.)

А MFC, ATL, VCL и прочие используются лишь для удобства работы с API. Очень даже явной работы (MFC), довольно смутной (мое мнение ATL), и вообще тщательно скрываемой (VCL).

SC>(есс-но за исключением особых случаев) Другое дело, что тут надо смотреть возможность человека сделать шаг влево — вправо. Например, на Delphi мне пришлось изрядно ... Может я их не понимаю, может еще чего. А на VC — на ура. А API — это из оперы "все знать нельзя".

А все знать и не надо — понимать надо, принципы там и т.п.

SC>Сервис писать — это одно. А вот интерфейс городить или еще чего — тут можно вспомнить, что проги под Win можно и на ASMe писать

А зачем об этом вспоминать-то?

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

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

E>По-моему программа не из одного GUI состоит. Если человек написал программу с "крутым" GUI с меньшими усилиями, значит у него остается больше сил и времени для реализации прикладной задачи, чем утого, кто написал программу с "крутым" GUI но на голом API. А следовательно с прикладной точки зрения, программа первого должна быть "круче", чем у второго.

Это если принять, что тот, кто "написал программу с крутым GUI с меньшими усилиями" вообще сможет реализовать прикладную задачу. Вообще, по-моему, Delphi как раз и позволяет не "писать крутой GUI", а просто собирать его для конкретной прикладной задачи. А вот если стандартных элементиков не хватает — вот тут начинаются так называемые "вилы". (это чтоб дам не смущать)

Вот только для написания более или менее изощренной прикладной части — с точки зрения структур-алгоритмов — больше C++ подходит. Это опять таки лишь мое скромное мнение...

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

B> И еще. Ни Delphi, ни VB ни другое средство визуального программирования совершенно не подходят для начинающих, ибо все программирование для них просто закрывается и написание программ сводится к "рисованию" простеньких интерфейсов. А умение аналитически мыслить, умение составлять алгоритмы и т.д. само по себе никогда не прийдет. И в этом смысле люди, пропагандирующие подобны средства для новичков, оказывают им медвежью услугу как будующим профессионалам. И поскольку кажущаяся легкость работы на Delphi или на VB и их доступность привлекают именно новичков, то потом уже не удивляешься когда слышишь не очень лестные мнения о программистах, работающих на Delphi. Хотя как кто-то ухе говорил — нельзя стричь всех под одну гребенку.

Ну и почему же это "ни Delphi, ни VB, ни другое средство визуального программирования совершенно не подходят для начинающих"? Может в том, что "все программирование для них просто закрывается и написание программ сводится к "рисованию" простеньких интерфейсов" виноваты лишь обучающие книги-курсы и т.п.? Вы знаете, даже меня, все кое что видевшего человека, весьма удручает написать пару тысяч строк только для того, чтобы что-то можно было хотя бы запустить. А потом еще пару тысяч чтобы дописать еще что-то. Но я то приблизительно знаю, что делаю и что должно получиться. Иногда...

Так может проблема не в визуальных средствах разработчика, а в обучении программированию, собственно разработке?

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

CL>Много всего интересного сказали и я не могу остаться в стороне.

CL>Расскажу одну правдивую историю. несколько лет пишу на VC++ и уже неплохо с ней знаком. А тут вдруг интересно стало — кто такая дельфи? Паскать 7.0 я когда-то изучал, поставил себе Delphi 6 и... сразу создал рабочее приложение.

Т.е. вобще без книжек безо всего — это говорит о простоте дельфи.

А я вот, после программирования на разных там C/C++, тоже, кстати, от Borland, решил было за Delphi сесть. Да не тут-то было! Тама толпа каких-то компонентов с не меньшей тольпой каких-то свойств и вообще невесть что. Это уже потом, вдоволь напрограммировавшись под Win с помощью OWL и прочитав (пролистав) как-то за ночь увесистый том о Delphi я "въехал" в эту среду.

CL>А вобще работодатели дельфю любят (это мое мнение). Т.к. дельфи программист раз-два и собрал программу. Неважно, что она УЖЕ весит больше мегабайта. Неважно, что постоянно вылезают глюки. Не важно, что для того чтобы работать с базами данных надо устанавливать дельфю на целевой компьютер (сам с этим сталкивался, когда мне предложили поюзать дельфовую прогу юзающую BDE). Зато быстро!

Глупости! Насчет скорости создания и продолжения разработки на Delphi — это не совсем так радужно. Что-то очень простое — очень быстро. Ну а дальше: "Чем дальше в лес, тем толще партизаны"!

CL>Итак, я считаю — Visual C++ ONLY & FOREVER. Но если знаешь дельфи, сказать об этом никогда не вредно. Вобще, чем больше знаешь, тем лучше. думаю работодатели это оценят. :-

Не факт. Иногда вообще не стоит говорить, иногда соверешенно не стоит ставить его в начало списка "APPLICATION DEVELOPMENT TOOLS" — зависит от того, куда устраиваешься и что там от тебя хотеть будут. "Нужно провести разведку боем! Для чего? Да кто их разберет!"

Я говорю хватит толочь воду в ступе! У всех языков есть свои плюсы и свои минусы и каждый из них заточен для решения определенных задач. И спорить что лучше — бесполезное занятие. Поэтому предлагаю закрыть эту тему и больше к ней не возвращаться. Никогда. А кто вернеться — бомбить нулями

и молчать

Какие будут возражения?

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

TL>Ну и почему же это "ни Delphi, ни VB, ни другое средство визуального программирования совершенно не подходят для начинающих"? Может в том, что "все программирование для них просто закрывается и написание программ сводится к "рисованию" простеньких интерфейсов" виноваты лишь обучающие книги-курсы и т.п.? Вы знаете, даже меня, все кое что видевшего человека, весьма удручает написать пару тысяч строк только для того, чтобы что-то можно было хотя бы запустить. А потом еще пару тысяч чтобы дописать еще что-то. Но я то приблизительно знаю, что делаю и что должно получиться. Иногда... :)

Вот видите. Вы же не начинающий. Я могу только повторить только то, что сказал и сказали до меня в предыдущих сообщениях. На мой взгляд программирование — это скорее образ мышления. Программист должен уметь анализировать, уметь разрабатывать алгоритмы, знать принципы работы компъютера и т.д. Если человек не освоил хотя бы элементарных приемов построения алгоритмов, то можно ли его назвать хоть в какой-то мере программистом. У меня были подобные случаи, когда человек был не в состоянии составить простейший алгоритм и описать его хотя бы на русском языке. Он только начинает и это вполне естественно. Поэтому приходится размышлять вместе с ним, показывать как можно составить алгоритм, как разделить задачу на отдельные шаги, как употреблять те или иные программные конструкции. Он учится мыслить.
А возьмите любые книги по Delphi или VB. Там же просто описывается та или иная среда программирования. Делается упор на легкость создания приложений. Часто подчеркивается, что можно создать приложение не написав не единой строчки кода. Но если это так, то тогда о каком программировании здесь можно вести речь? Я понимаю, если Вы человек с достаточным опытом, то система визуального программирования это мощный инструмент, один из нескольких, которыми Вы пользовались ранее или продожаете пользоваться сейчас. А что это за инструмент для начинающего? Да, он сможет сделать простейшее приложение, и достаточно быстро. Но когда помимо интерфейса потребуется сделать еще кое-какую обработку и там потребуются те навыки, о которых я уже говорил, то сможет ли он что-то сделать? Это что — тупик? И здесь я согласен с Вами целиком и полностью.

TL>Так может проблема не в визуальных средствах разработчика, а в обучении программированию, собственно разработке?

Дело не в визуальных средствах как таковых, а дело в обучении программированию. Но ...
Но на мой взгляд визуальные средства программирования собственно программирование и скрывают в силу самой их природы. Ведь для того, чтобы обучить человека навыкам программирования вся мощь Delphi, VB и подобным системам абсолютно ненужна. Цель обучения не построение приложения в Windows, а имено умение мыслить. А возможность практического использования учебных программ отходит если не на последний план, то во всяком случае занимает далеко не первое место. Учебные программы, особенно на начальном этапе, достаточно просты и для их программирования можно использовать сравнительно простые средства, да и Windows использовать совершенно не обязательно, достаточно старенькой DOS. В качестве среды для проектирования я считаю наиболее лучшим Borland C++ V3.1 для DOS. Эта среда сама по себе достаточно мощная и, в тоже время, достаточно простая и здесь нет необходимости изучать много того, что к программированию непосредственно не относится. Конечно, могут быть и другие мнения. Возможно кто-то скажет, что лучше использовать Pascal или что-то еще. Во всяком случае я думаю, что чем проще среда — тем лучше.
Если говорить о себе, то я начинал программировать, когда не то что компилятора, но даже и ассемблера какого-нибудь подходящего под рукой не было (оговорюсь речь идет о микропроцессорах). Приходилось писать в машинных кодах, позднее перешли на ассемблер, а затем на C. И сейчас хоть и приходится программировать достаточно много, но все-таки все мои программы так или иначе связаны с "железом". Но и здесь наличие удобной и мощной среды программирования очень необходимо. Поэтому я положительно отношусь к любой среде, была бы она надежной и удобной. А спор какая из них самая самая я не понимаю. Здесь часто зависит от личных симпатий или антипатий. Конечно хорошо, когда выбор инструмента определяется более или менее объективно в соответствием с какими-то критериями, но в этом случае обычно в крайности не впадают и не обвиняют в непрофессиональности всех и вся лишь только потому, что те пользуются "не той" системой. Прошу извинить за мое многословие.

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

CL>Я говорю хватит толочь воду в ступе! У всех языков есть свои плюсы и свои минусы и каждый из них заточен для решения определенных задач. И спорить что лучше — бесполезное занятие. Поэтому предлагаю закрыть эту тему и больше к ней не возвращаться. Никогда. А кто вернеться — бомбить нулями

и молчать

CL>Какие будут возражения?

Никаких!

Бомбите меня нулями!!!

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

CL>После прочтения книжки про дельфи нашел одну интересную хозму (вот C++ программеры посмеются). Вызов чисто вируальных методов класса отслеживается не на этапе компиляции, а на этапе выполнения. :)))

CL>Вобще, надо сказать, очень убогий оптимизатор у борланда. Что у дельфей, что у бильдера. Это не мое личное мнение, это все эксперементально подтверждено.

Хочешь супер оптимизацию пиши на асемблере !
Не в оптимизации дело а вскорости разработки и качестве , на VC простой диалог геморойно делать !

CL> Неважно, что она УЖЕ весит больше мегабайта. Неважно, что постоянно вылезают глюки. Не важно, что для того чтобы работать с базами данных надо устанавливать дельфю на целевой компьютер (сам с этим сталкивался, когда мне предложили поюзать дельфовую прогу юзающую BDE). Зато быстро! :down:

Если ты пишешь на VC наверняка пользуешься mfc а ее размер тоже около мегабайта
глюки вылезают не из зи дельфи а из за програмера
а BDE уже давно никто не юзает ( есть много альтернатив )

CL>Итак, я считаю — Visual C++ ONLY & FOREVER. Но если знаешь дельфи, сказать об этом никогда не вредно. Вобще, чем больше знаешь, тем лучше. думаю работодатели это оценят. :-
S>>Часто приходится слышать мнение, что разработчики, использующие delphi -
S>>ваще не программисты, а так... детишки неразумные.
S>>Ясно, что у нее (как и у каждого ср-ва разработки) есть свои минусы,
S>>но и плюсы тоже имеются. Я, например, юзаю с равной интенсивностью и
S>>delphi, и vc++, и MASM. И что, об этом лучше никому не говорить?
S>>По-вашему, чем вызвано такое негативное отношение?

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

D>... пытасюь выбросить из головы Foxpro,VFP и прочую лабудень,
D>... Начинаю изучать с нуля WINAPI, принципы работы с базами данных, Ц++......

Многие говорят, что WINAPI изучать не стоит. Ты решай конечно сам, а я так думаю, что с изучения WINAPI как раз нужно начинать. Я лично не люблю MFC (это мое личное мнение — никому не навязываю и спорить не собираюсь).
По этому поводу см. хорошую статью:
http://www.softcraft.ru/coding/winapi/mfcbad.shtml

Что касается WINAPI — советую прочитать в первую очередь книгу Ч.Петзолда "Программирование для Windows 95". Ну и Рихтера, конечно. Есть электронные версии.

COM и ATL изучать можно с книгой Трельсена (не помню точное название). Кстати, эта книга дает представление не только о COM, но и о интерфейсном программировании вообще. Очень рекомендую.

Ну и напоследок, welcome на мой сайт: http://cprime.hypermart.net

ЗЫ: Очень прошу не начинать спор по поводу "вредности" MFC. Каждая технология хороша по-своему.

Да, флеймерный тред получился. Смысл спорить, когда уже всем ясно, что писать программы нужно на ассемблере?

>Не в оптимизации дело а вскорости разработки и качестве , на VC простой диалог геморойно делать !

Ерунда — простой диалог сварганить — как два байта переслать. Берешь любой нормальный редактор ресурсов и визуально лепишь свои контролы без всяких проблем.

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

A>Ерунда — простой диалог сварганить — как два байта переслать. Берешь любой нормальный редактор ресурсов и визуально лепишь свои контролы без всяких проблем.

Угу. Особенно клево эти Control-ы ставятся на странички
PageControl

А так же очень хорошо сами расползаются при
растягивании дилога

Вообщем слово простой здесь ключевое.

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

A>>Ерунда — простой диалог сварганить — как два байта переслать. Берешь любой нормальный редактор ресурсов и визуально лепишь свои контролы без всяких проблем.
A>Угу. Особенно клево эти Control-ы ставятся на странички
A>PageControl

А так же очень хорошо сами расползаются при
A>растягивании дилога

A>Вообщем слово простой здесь ключевое.

Безусловно. Но человек жаловался на то, что он не мог сделать _простой_ диалог. Мой ответ был направлен на то, чтобы он понял, что сделать простой диалог вовсе не сложно даже без Дельфи.

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

S>Часто приходится слышать мнение, что разработчики, использующие delphi -
S>ваще не программисты, а так... детишки неразумные.
S>Ясно, что у нее (как и у каждого ср-ва разработки) есть свои минусы,
S>но и плюсы тоже имеются. Я, например, юзаю с равной интенсивностью и
S>delphi, и vc++, и MASM. И что, об этом лучше никому не говорить?
S>По-вашему, чем вызвано такое негативное отношение?

Сколько людей столько мнений...

Но... Много из прочитанного здесь -- это еси война миров, конечно когда-то програмеры больше воревали, чем сейчас.
Страсти уляглись...
Но!!! Когда кто-то кричит: "Моё корыто лучше, а твоё нет" -- стыдно же...

Поэтому я в качестве аналитика делаю свой экскурс...

Первая книга по Билдеру попавшаяся мне на глаза начиналась такими строчками: "Мы все ещё живём в эпоху компонентов..."
(Не люблю зар авторов, любят они много воды лить... (кроме некотороых приятных исключений))

Чесное слово -- врёт и некраснеет. В действительности: "Мы асе живём в эпоху процедурного программирования"
Которое проявляеться как ООП-абстракция, модули, и т.д.
Но наш код — по прежнему набор процедур в своей сути.

Програмисты так давно ищут как инкапсулировать работу, что свихнулись. ООП, модули -- это первые попытки.

Но идея VCL по истене оказалось замечательной.... хотя и ошибочной. Некоторые зададки -- это перспективы будущего "чистого визуального программирования", но так как это сделано в VCL — похоже на жалкую пародию самой её идеи.

Без сомнения будущее кроется в технологиях абстрагирования кода, однако, (моё личное мнение) дорога по которой сейчас пошли не очень хороша. Особенно тот путь, по которому пошло Interprice... Обидно, и ещё как.

Когда встаёт вопрос на чёи програмить, что знать, что уметь...
Я недавно пореккомендовал перейти на Delphi для учеников, чтобы тем самым подстегнуть интерес к программированию.
Но теперь считаю, что жестоко ошибся, потому что Delphi в качестве обучения "свёртывает мозги".
Для становленных программистов -- это не страшно, но для начинающих — это кол в грудь, или в голову.

С точкии зрения профессионального использывания, то идея VCL хороша.
Представте разработку большого проекта:

1. Один штат програмеров делает компоненты
2. Другие, толкьо работаю с ними.

В этом случае можно достичь униканой эффективности!! Максимальной.

Но архитектура VCL -- препятствует такой светлой идее.

Что тут сказать.

Другое странно, почему так много дельфистов идут в асмовские ряды?
До сихз пор как психологу мне это не понятно.
Тем более я замечаю (как уже говорил) некое нехорошее отличие в мышлении этих учеников...

Другая сторона медали:

Использование Дельфи плохо для больших проектов.
Его эффективность проявляеться в средних продуктах...

Мой вердикт:

Для обучения : Не годится!!!
Для работы: Только для личных проектов...

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

A>Безусловно. Но человек жаловался на то, что он не мог сделать _простой_ диалог. Мой ответ был направлен на то, чтобы он понял, что сделать простой диалог вовсе не сложно даже без Дельфи.

Здесь ты маленько не угадал.
Для дельфистов простое обозначает не что Control-ов мало а что
писать руками ничего не надо

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

E>Другое странно, почему так много дельфистов идут в асмовские ряды?
E>До сихз пор как психологу мне это не понятно.
E>Тем более я замечаю (как уже говорил) некое нехорошее отличие в мышлении этих учеников...

Точно. Подтверждаю.
Большинство и моих знакомых увлечённых асмом, предпочитают Delphi.
Почему так? Это интересная психологическая задача.

Предположу.
Дело наверное в радости про которую писал Gosha.
Не радостное наверное это дело — писать на паскале...
Надёжно, удобно, эффективно.
Но не радостно.

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

Рек>Предположу.
Рек>Дело наверное в радости про которую писал Gosha.
Рек>Не радостное наверное это дело — писать на паскале...
Рек>Надёжно, удобно, эффективно.
Рек>Но не радостно.
Рек>

Торгует мужик на базаре надувными шариками.
— Сколько стоят шарики? — спрашивают его.
— Рупь, — говорит, — только вы их не покупайте, они бракованные.
— Что? Не надуваются?
— Не. Надуваются, ещё как надуваются!.
— Что тогда? Лопаются?
— Неа. Не лопаются.
— А чтоже тогда?
Мужик тяжело вздышает и говорит
— Не радуют...

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

A>Да, флеймерный тред получился. Смысл спорить, когда уже всем ясно, что писать программы нужно на ассемблере?

Во-во!!! Так и надо

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

A>>Безусловно. Но человек жаловался на то, что он не мог сделать _простой_ диалог. Мой ответ был направлен на то, чтобы он понял, что сделать простой диалог вовсе не сложно даже без Дельфи.
A>Здесь ты маленько не угадал.
A>Для дельфистов простое обозначает не что Control-ов мало а что
A>писать руками ничего не надо

Гы. А потом они еще и жалуются, что это называют "мышиной возней"

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

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

D>>... пытасюь выбросить из головы Foxpro,VFP и прочую лабудень,
D>>... Начинаю изучать с нуля WINAPI, принципы работы с базами данных, Ц++......

E>Многие говорят, что WINAPI изучать не стоит. Ты решай конечно сам, а я так думаю, что с изучения WINAPI как раз нужно начинать. Я лично не люблю MFC (это мое личное мнение — никому не навязываю и спорить не собираюсь).
E>По этому поводу см. хорошую статью:
E>http://www.softcraft.ru/coding/winapi/mfcbad.shtml

E>Что касается WINAPI — советую прочитать в первую очередь книгу Ч.Петзолда "Программирование для Windows 95". Ну и Рихтера, конечно. Есть электронные версии.

E>COM и ATL изучать можно с книгой Трельсена (не помню точное название). Кстати, эта книга дает представление не только о COM, но и о интерфейсном программировании вообще. Очень рекомендую.

E>Ну и напоследок, welcome на мой сайт: http://cprime.hypermart.net

E>ЗЫ: Очень прошу не начинать спор по поводу "вредности" MFC. Каждая технология хороша по-своему.

Списибо за добрый совет. Как раз сейчас и начал с Петзольда, мое имхо таково, что библиотека MFC рано или поздно загнется,
а WINAPI — он и в Африке API, к тому же сама MFC не что иное как каркас, построенный на WINAPI и оне не дает такого представления о программировании и о внутреннем устройстве WINDOWS, как WINAPI. Ничего против MFC не имею, вещь хорошая, но изучать надо не с нее.... хотя для разработки приложений она очень нужна и экономит кучу времени — с этим тут не поспоришь....

Но для начинающего программера на VC++ , каким являюсь я, необходимо знание самого С++ и WINAPI/

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

[skipped]

E>Мой вердикт:

E>Для обучения : Не годится!!!
E>Для работы: Только для личных проектов...

Коллега, дык ия о том же

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

DM>>Ну и совсем не правда!

)) Нет, тут, как мне кажется, явно что-то не так, как хотелось бы...

Профи — человек, зарабатывающий себе на жизни определенной профессией. Дело не в инструменте.

Но если профи в Win32 — этот чел однозначно не дельфист, а VCшник

Здравствуйте Ибрагим, Вы писали:

И>Но если профи в Win32 — этот чел однозначно не дельфист, а VCшник

Враки! Лично я являюсь опровержением этих гнусных измышлений.

Здравствуйте Ибрагим, Вы писали:

ИИ>Профи — человек, зарабатывающий себе на жизни определенной профессией. Дело не в инструменте.

И>Но если профи в Win32 — этот чел однозначно не дельфист, а VCшник

Мля, бесконечная тема какая-то

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

И это... Может закроем тему,а?

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

ИИ>>Профи — человек, зарабатывающий себе на жизни определенной профессией. Дело не в инструменте.

И>>Но если профи в Win32 — этот чел однозначно не дельфист, а VCшник

S>Мля, бесконечная тема какая-то

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

Загляти в толковый словарь для начала. При чем здесь результаты ?

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

И>>Но если профи в Win32 — этот чел однозначно не дельфист, а VCшник

A>Враки! Лично я являюсь опровержением этих гнусных измышлений.

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

Возможго, что тебе Долфи нравится. Но это еще ничего не значит. Дельфист — постоянно сидящий в дельфи и презирающий VC.

Здравствуйте Ибрагим, Вы писали:

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

И>>>Но если профи в Win32 — этот чел однозначно не дельфист, а VCшник

A>>Враки! Лично я являюсь опровержением этих гнусных измышлений.

И>Ты так думаешь ? Скорее всего ты заблуждаешься. Смотрю твои мессаги, про дельфи там очень мало.

И>Возможго, что тебе Долфи нравится. Но это еще ничего не значит. Дельфист — постоянно сидящий в дельфи и презирающий VC.

Тебе самому не смешно?

Человек который постоянно сидит в Delphi (например в силу специфики работы) и любит VC — это что уже "VCшник"?

Можут тему новую открыть? А?
А то, что-то вы совсем забыли о Delphi

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

A>>>Враки! Лично я являюсь опровержением этих гнусных измышлений.

И>>Ты так думаешь ? Скорее всего ты заблуждаешься. Смотрю твои мессаги, про дельфи там очень мало.

И>>Возможго, что тебе Долфи нравится. Но это еще ничего не значит. Дельфист — постоянно сидящий в дельфи и презирающий VC.

Y>Тебе самому не смешно?

Y>Человек который постоянно сидит в Delphi (например в силу специфики работы) и любит VC — это что уже "VCшник"?

Y>

VCшник — постоянно сидит в VC и презирает(возможно) Дельфи.

Все остальное — ни рыба, ни мясо. Вот.
Если челу чтото нравится и он в нем много умеет — это еще не повод называть его профи. Профи — от слова профессия. Если профессия не нравится челу — он не профи !

Здравствуйте Ибрагим, Вы писали:

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

A>>>>Враки! Лично я являюсь опровержением этих гнусных измышлений.

И>>>Ты так думаешь ? Скорее всего ты заблуждаешься. Смотрю твои мессаги, про дельфи там очень мало.

И>>>Возможго, что тебе Долфи нравится. Но это еще ничего не значит. Дельфист — постоянно сидящий в дельфи и презирающий VC.

Y>>Тебе самому не смешно?

Y>>Человек который постоянно сидит в Delphi (например в силу специфики работы) и любит VC — это что уже "VCшник"?

Y>>

И>VCшник — постоянно сидит в VC и презирает(возможно) Дельфи.

И>Все остальное — ни рыба, ни мясо. Вот.
И>Если челу чтото нравится и он в нем много умеет — это еще не повод называть его профи. Профи — от слова профессия. Если профессия не нравится челу — он не профи !

Вот у меня проффесия программист и я разрабатываю на данный момент три проекта

1. Игру под мобильный телефон на Java
2. Игру для PC на Delphi
3. Игру для PC на VC

С ваших слов получаеться что профи я быть ни как не могу, в не зависимости от моих знания потому как я "ни рыба, ни мясо".

Вам не кажеться что вы не логичны?

Y>>Человек который постоянно сидит в Delphi (например в силу специфики работы) и любит VC — это что уже "VCшник"?

Y>>

И>VCшник — постоянно сидит в VC и презирает(возможно) Дельфи.

И>Все остальное — ни рыба, ни мясо. Вот.
И>Если челу чтото нравится и он в нем много умеет — это еще не повод называть его профи. Профи — от слова профессия. Если профессия не нравится челу — он не профи !

Разбор полётов:

Статистика:

Более 50% рабочих работаю на работе, при этом не испытывая большой любви к ней...
Более 70% студенов поступаю не туда куда призваны

Более 100% ваших мессаг -- офтопик

Если программист удиляет такое внимание важности инструмента на котором он "творит чудеса", то он вообще говоря забывает о сути программирования.

ОСТАНОВИТЕСЬ ПОКА НЕ ПОЗДНО!!!
Уважаемые профессионалы!!!

Здравствуйте Ибрагим, Вы писали:

И>VCшник — постоянно сидит в VC и презирает(возможно) Дельфи.

Почему если человеку нравится один продукт он обязательно должен презирать
другой? мне вот нравится Borland C++ Builder. Я сейчас пишу на VC.
к Delphi я тоже вполне лояльно отношусь хотя сам на нем почти
не пишу, не люблю что в pascal нет STL и переменные нельзя
в циклак описывать.

Но я ничего из этого не презираю. Я даже к VB вполне лояльно
отношусь.

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

E>Более 70% студентов поступаю не туда куда призваны

Угу призывают их в армию, а они идут в институт в
место этого

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

Y>Вот у меня проффесия программист и я разрабатываю на данный момент три проекта

Y>1. Игру под мобильный телефон на Java
Y>2. Игру для PC на Delphi
Y>3. Игру для PC на VC

Y>С ваших слов получаеться что профи я быть ни как не могу, в не зависимости от моих знания потому как я "ни рыба, ни мясо".

Y>Вам не кажеться что вы не логичны?

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

S>Часто приходится слышать мнение, что разработчики, использующие delphi -
S>По-вашему, чем вызвано такое негативное отношение?

Вариант.

Просто есть main stream разработки систем (не только программ) широкого потребления, где условия диктует MS:

OS — Windows
ЯП :) для сложных систем — VC
ЯП для быстрой разработки низко квалифициованным персоналом — VB

Все остально имее налет несерьезности: что Linux (ой! я, кажется, попал :), что Delphi, хотя сравнивая Delphi и VC еще можно покрихтеть и согласиться, что "это смотря что кодировать", то при сравнении Delphi и VB, второй отдыхает, по причине своей изначальной дебильности.

Да еще эта чехарда Borland/Inprise/Borland, а вы вспомните как мы спрашивали др. у друга, "А правда, что 6 билды не будет? А правда, что Borland разорилась?", все это влияет и на восприятие продуктов. А какому менеджеру хочется (и есть время, что бы) разбираться _что_ и _как_ вы там пишете, ему главное, чтоб проблем с поддержкой и кадрами не было после разработки.

А если билды .нет не будет? А будет только Kylix "там" и Delphi "сдесь", а кто тут может сказать, что такой вариант исключен?

Да еще VCL, все-таки очень жесткая framework, да сделать там клевый интерфейс (пускай, скорее всего, нестандартный, надиктованый MS, через MSOffice) просто, но чтоб сделать его еще клевей, а самое главное таким, чтоб ни укого не было (и в тоже время стандартным чтоб оставался), чем это предполагалось, извините, придется вам давиться почище чем на VC, придется перечитать туеву хучу исходников (не документации, а именно исходников) и пробывать, пробывать, пробывать. Да, после этого вы станете Профи и вы растопчите любую MFC-шавку... но... но в следующей версии VCL, у вас, ксожалению, это работать не будет, хотя об этом вам честно скажут в readme.txt, а перед этим уведомят в рассылке.

Мы с таким уже сталкивались, после чего забили на VCL большой болт и используем его только для эскизирования интерфейсов, очень это удобно там делать, лучше, чем в Visio, по крайней мере :)))

И>Профи в чем ? Профи — это лэйба типа офицерского звания.
И>Ты профи в игрушках, возможно, если постоянно этим занимаешься.
И>Так что все логично.

Т.е. по вашему человек не может быть профи в нескольких вешах одновременно?

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

И>>Профи в чем ? Профи — это лэйба типа офицерского звания.
И>>Ты профи в игрушках, возможно, если постоянно этим занимаешься.
И>>Так что все логично.

Y>Т.е. по вашему человек не может быть профи в нескольких вешах одновременно?

Профессионал — человек зарабатывающий определенной профессией на жизнь. Разнорабочий — не профессионал.

Если ты умеешь готовить очень хорошо — это не значит, что ты профессиональный повар.
Когда ты занимаешься чем то профессионально, зачем тебе еще одна профессия ? Потому что основная не дает заработка ? Абсурд.

Профессионал — применяется к определенной предметной области, а не инструменту.
Профессионализм подразумевает очень глубокие знания в одной, узкой, области.

Профессионал — человек, знающий все ни о чем. Смежный предметные области ты будешь хорошо знать, но не профессионально.

Чем отличается профессионал от опытного программиста непрофессионала ? Профессионал обзан решать все проблемы, возникающие на пути. Если проект требует прыжка через голову или предусмотрения 1000 мелочей, то профессионал должен это сделать. Иначе проект не сдаст и кушать будет не на что.

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

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

TL> Не знаю как вы, а я, например, просто в шоке от кода ADO под C++. Вот в VB это просто очаровательно! Но в C++ — нет, увольте!

Это вот вот такого кода?

try
{
    _ConnectionPtr oConnection1(__uuidof(Connection));

    oConnection1->CursorLocation = adUseClient;
    oConnection1->Open("Provider=SQLOLEDB;Data Source=MySrvr;Initial Catalog=Northwind","MyId", "123aBc", 0);

    _RecordsetPtr m_oRecordset1(__uuidof(Recordset));

    m_oRecordset1->Open("SELECT ProductID, ProductName, CategoryID, UnitPrice FROM Products",
                        variant_t(oConnection1), adOpenStatic, adLockBatchOptimistic, adCmdText);

    m_oRecordset1->MarshalOptions = adMarshalModifiedOnly;

    m_oRecordset1->ActiveConnection = 0;
    oConnection1->Close();
}
catch(_com_error& e)
{
}

По-моему, код на Basic немногим отличается.

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

EB>- Большинство испольэзует С++.

Это высказывание тоже неверно. Более правильно "Большинство использует подмножество C++, совпадающее по приемам с C". Ибо, как я заметил, везде шарахаются даже от перегрузки операторов и шаблонов по причине "но ведь это сложно и в VB этого нету", а также "нам надо сдать проект, половина разработчиков не может сидеть и разбираться, что такое шаблон!"

Здравствуйте m.a.g., Вы писали:

...>Это высказывание тоже неверно. Более правильно "Большинство использует подмножество C++, совпадающее по приемам с C". Ибо, как я заметил, везде шарахаются даже от перегрузки операторов и шаблонов по причине "но ведь это сложно и в VB этого нету", а также "нам надо сдать проект, половина разработчиков не может сидеть и разбираться, что такое шаблон!"

Ну не сказал бы ты посмотри какие вопросы летают в конфе по C++

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

A>Здравствуйте m.a.g., Вы писали:

...>>Это высказывание тоже неверно. Более правильно "Большинство использует подмножество C++, совпадающее по приемам с C". Ибо, как я заметил, везде шарахаются даже от перегрузки операторов и шаблонов по причине "но ведь это сложно и в VB этого нету", а также "нам надо сдать проект, половина разработчиков не может сидеть и разбираться, что такое шаблон!"

A>Ну не сказал бы ты посмотри какие вопросы летают в конфе по C++

Я говорил про работодателей и менеджеров. А если ты имеешь в виду вопросы типа "lg на этапе компиляции", то ведь немного наберется людей, которые эти темы обсуждают.

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

EB>Здравствуйте:

EB>Тут прозвучало множество неверных высказываний:

EB>- Большинство испольэзует С++.
На самом деле можно заменить на дольшинство использует
Microsoft VC++ а не Borland Delphi

EB>- Object Pascal несовместим с С, поэтому приходится жутко переделывать интерфейс к библиотекам

На это время уходит. Хорошо если библиотека не большая,
а если большая? Возьми например и попробуй заново написать
windows.pas на это у тебя пол года то уйдет наверняка.
А библиотеки и поболе бывают.

Посмотри кстати вот этот ответ. Он совсем под тему
подходит http://rsdn.ru/forum/?mid=82529

EB>Вы же прекрасно знаете что эта переделка сводится к замене синтаксиса С на синтаксис Паскаля. На "бинарном уровне" ничего делать не надо, все совместимо.

Утверждение вообще не в тему. Подмена понятий.

EB>MFC можно считать образцом того, как не надо писать библиотеки на C++. И чему же человек учится? Плохому стилю программирования на C++

WinAPI, а его собственная возможность писать хорошо
структурированный код приходит когда он онимает что с этой
массой кода надо что-то делать. Про Delphi кстати я вообще
молчу. Там навязываентся совсем другой стиль програмирования,
плохой. Навязывается он дизайнером.

EB>Дельфи дает простоту и скорость, причем сделано это уже давно, причем сочетается с быстротой вып-я программы, т. к. Дельфи делает настоящие экзешки. И вот теперь, через 6 лет, MS преподносит свое "открытие", которое даже не не компилирует в exe и требует огромных системных ресурсов.

Да никто не говорит что Delphi безполезна просто не стоит утверждать
что программировать надо только на Delphi.

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

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

EB>>Здравствуйте:

EB>>Тут прозвучало множество неверных высказываний:

A>На это время уходит. Хорошо если библиотека не большая,
A>а если большая? Возьми например и попробуй заново написать
A>windows.pas на это у тебя пол года то уйдет наверняка.
A>А библиотеки и поболе бывают.

Незачем сразу все переписывать. Встретил нужную функцию --
добавил ее.
Есть люди которые этим занимаются для общего дела. Тот же
jedi, например.
Но доп. сложностей не отрицаю. Зависит от того, какие
приложения надо писать.

A>Посмотри кстати вот этот ответ. Он совсем под тему
A>подходит http://rsdn.ru/forum/?mid=82529

Немного в сторону: на Дельфи лучше писать 'родные' компоненты,
использующие API БД напрямую. Они гораздо быстрее и удобнее.

A>Утверждение вообще не в тему. Подмена понятий.

Очень даже в тему. Ответ на "Object Pascal несовместим с С".

A>WinAPI, а его собственная возможность писать хорошо
A>структурированный код приходит когда он онимает что с этой
A>массой кода надо что-то делать.

WinAPI лучше изучать, сразу создавая программы непосредственно
на нем. Делать ли это на C, на Делфи -- разницы нет (кроме
загол. файлов). Некоторый вообще считают, что API лучше на
ассемблере изучать (см. http://www.wasm.ru) Говорить,
нужно ли вообще программы писать на API можно долго.

A> Про Delphi кстати я вообще
A>молчу. Там навязываентся совсем другой стиль програмирования,
A>плохой. Навязывается он дизайнером.

Вы считаете компонентное программирование плохим? Не все с вами
согласятся. И что вы подразумеваете под стилем, навязываемым
Дельфи непонятно. VCL хорого продумана и выдержана.

A>Да никто не говорит что Delphi безполезна просто не стоит утверждать
A>что программировать надо только на Delphi.

А я этого и не утверждал. Просто попытался развеять хрестоматийные
заблуждения.

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

A>> Про Delphi кстати я вообще
A>>молчу. Там навязываентся совсем другой стиль програмирования,
A>>плохой. Навязывается он дизайнером.

EB>Вы считаете компонентное программирование плохим? Не все с вами
EB>согласятся. И что вы подразумеваете под стилем, навязываемым
EB>Дельфи непонятно. VCL хорого продумана и выдержана.

У тебя заблуждение в понятии "Компонентное" если ты
думаешь что это то которое состоит из TComponent-ов ты
ошибаешься.

Я тебе могу сказать в чем проблема у Delphi. Когда ты создаешь
событие то оно получается published ходя не имеет отношение
к другим классам. Это нарушает инкапсуляцию. На самом деле
можно эти функции вынести в private но никто этого не делает
т.к. в таком состоянии dfm не загружается. Второй пример
что почти не используется наследование а пользуется вставка
копирование между событиями. Такой стиль получается т.к.
в нем легче программироват в Delphi(по мелочам) но при
этом получается что структура программы не продумана.

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

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

A>У тебя заблуждение в понятии "Компонентное" если ты
A>думаешь что это то которое состоит из TComponent-ов ты
A>ошибаешься.

TComponent обеспечивает манипулирование в design-time.
Компоненты могут быть визуальными и невизуальными.
Выгода компонентов -- кодирование заменяется на конструирование
в design-time (не полностью, конечно). Чем меньше пишется кода,
тем меньше делается ошибок.

A>Я тебе могу сказать в чем проблема у Delphi. Когда ты создаешь
A>событие то оно получается published ходя не имеет отношение
A>к другим классам. Это нарушает инкапсуляцию. На самом деле
A>можно эти функции вынести в private но никто этого не делает
A>т.к. в таком состоянии dfm не загружается.

Не надо использовать формы напрямую. Создается класс-оболочка,
который один видит и использует форму.

A>Второй пример
A>что почти не используется наследование а пользуется вставка
A>копирование между событиями.
A>Такой стиль получается т.к.
A>в нем легче программироват в Delphi(по мелочам) но при
A>этом получается что структура программы не продумана.

1. Одну и ту же продуру-событие можно назначить n-компонентам легким
движением мыши.
2. Никто не запрещает вызывать их события процедуру.
3. Вы про ActionList слышали?

В общем не вижу чем это Дельфи принуждает использовать Copy/Past,
и чем C++ мешает.

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

EB>Не надо использовать формы напрямую. Создается класс-оболочка,
EB>который один видит и использует форму.

Решение верное.
Скупая статистика: в твоем текущем проекте сколько
форм и сколько классов оболочек?

A>>Второй пример
A>>что почти не используется наследование а пользуется вставка
A>>копирование между событиями.
A>>Такой стиль получается т.к.
A>>в нем легче программироват в Delphi(по мелочам) но при
A>>этом получается что структура программы не продумана.

Структура программы получается 2 уровневая. На первом
классы в линию. На на следующим их события и компоненты
кторые на них лежат. Про нормальную иерархию говорить не
приходится

EB>В общем не вижу чем это Дельфи принуждает использовать Copy/Past,
EB>и чем C++ мешает.

Она не принуждает, она поощьряет. Если у тебя 2 похожие формы
то по времени сильно быстрее раскопировать поведение, а не
выделить общее в отдельный класс и понаследоваться от него чтобы
реализовать разницу. Я понимаю что на Delphi можно и нормально
сделать, но никто не делает(даже я когда на ней пишу).

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

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

A>>Радикально неверное мнение!

A>>Т. е. Дельфы поддерживают и такое программирование тоже, но стричь всех, кто на них пишет, под одну гребенку — неверно.

DG>Во-первых, я имел ввиду большую (но все таки не всю) часть дельфистов.
DG>Во-вторых, если завтра взять двух достаточно умных людей, но которые не разбираются в программировании,
DG>и посадим их писать проги на Delphi, и на VC, то второму придется (хошь, не хошь) выучить больше о программирование, чем первому.
НЕ СОГЛАСЕН, абсолютно!!!
Второй просто ничего сделать не смогет месяцев несколька, а первый — легко.
Могу сказать, чт описать ГУИ на МФЦ — изврат, ибо библиотека дает крайне мало расширений к ГУИ. Мне, например проще реализовать все на ГУИ, чем разбираться с МФЦ (хотя я и ГУИ знаю и СиПП).
И вообще, сами ответы показывают какую-то нефилософскую предвзятость к Дельфи. А ответ, похоже, прост:
Программистам на Ц++ тжко отучиться от макросов и отсутствия проверки приведений типов и прочих "прелестей" Ц++ (например, множественное наследование — это круто (а уж наскока глючно — слов нету

), но ни разу не сталкивался с тем, что это — необходимость. Так — пальцы загнуть), а вот возьми и выйди система, которая на Паскал`е (!!!) позволяет разработать не менее (а иногда — и более) эффективные программы под Виндовс...
Плюс, остался предрассудок, что Паскаль ничего не умеет, хотя могу сказать точно: начиная версси этак с 6 (про седьмую — ваще молчу, ибо — КУУУЛЛЛ!!!!) вполне конкурентный язык.

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

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

Y>>Я например совершенно не вижу разницы например при написании какого нибуть сервиса для отслеживания обращения к диску например. И в куче других задач, в большенстве задач, разницы не будет.....
DM>Delphi всетаки предназначен для написания мелких и средних систем для работы в основном с БД. Соответственно на производстве он используется по назначению и написание сервисов отслеживающих чего-то там в большей степени исключение чем правило. А люди которые пишут клиентов на Дельфях в 90% случаях ламера.
"Чушь... и плешь!" — Copyright (c) by Robert Hainlein (Чужак в чужой стране).
Дельфи — это "RAD System — Rapid application Development System" т.е. система быстрой разработки приложений. нигде не вижу слов про БД... странно... то, что они исхитрились встроить в систему быстрый удобный и универсальный движок работы с БД — честь им и хвала. То, что я видел кучи прог написаных на VC в виде : берем сампл, чуть-чуть меняем, компиляем и выкладываем с криками, "что кул" и без необходимых библиотек, не значит, сто на VC одни придурки пишут. Исключения есть, везде и во всем. Терпимее надо быть...

Y>>Или вы считатет что человек который пишет проект используя MCF например знает априори меньше чем человек пришуший на чистом API?

DM>В определенных вещах ДА! Я имею ввиду конечно же не всех. Просто человек никогда не писавший на API, а только на MFC знает о "окнах" значительно меньше, чем API программера.
Ох. Профессионал отличается от ламмера не знанием того, чем версия 4564.4534.324.3242 Сам-API лучше версии 4564.4534.324.3241, а также знанием 1,000,000 разных API, а тем, что решает задачу наиболее эффективным способом, заа наименьшее время и с максимальным соблюдением ее постановки.
Пример1:
Если нужно сделать ОЧЕНЬ быстрый поиск в массиве целых чисел — он напишет реализацию на ассемблере
Пример2:
Если нужно просто окно для ввода пароля — он возьмет Дельфы или Васик (но никак не ВС — там хотя бы компиляция дольше идти будет).
Таким образом кричать, что: "Дельфы — ламмерская система!!!!!!!!!!!", — потому, что аж завидки берут, как там просто и непринужденно можно писать достаточно мощные проекты, а вот на ВС приходится потеть — вы не проффессионал, извините, а натуральный ламмер (в крайнем случае, на продвинутого юзверя тянете

).
ЗЫ Извините за резкозть — накипело. да и надоело слушать, что все надо выкинуть нафиг — все надо писать на Ц++ а базы данных реализовывать самостоятельно.

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

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

Y>>Там была формулировка — "крутую", я ее понял как "очень хорошую". Написание хорошого GUI — это очень весомы показатель, хороший GUI одинаково трудно создать и в Delphi и в VC.

DM>Ну и совсем не правда!

А я очень хотел бы увидеть исполнение СНОСНОГО, НО ПРАВИЛНО НАПИСАНОГО контрола для Дельфи написаного программером, всю жисть работавшим на Ц++ + МФЦ

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

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

SC>>Вот-вот

Представим, что у нас есть рельсина и от нее надо куско отрезать. И есть у нас три интструмента — кусок полотна, болгарка и автоген. И кого будем профи считать?

DG>Если вызовем трех людей, дадим одному полотно, второму болгарку, а третьему автоген — и они все в троем разрежут рельс, то профи скорее всего первый.

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

болгарка — тоже инструмент для этих целей, а разрез более ровный

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

A>Здравствуйте Ибрагим, Вы писали:

И>>Но если профи в Win32 — этот чел однозначно не дельфист, а VCшник

A>Враки! Лично я являюсь опровержением этих гнусных измышлений.
Присоединяюсь. хоть и знаю Ц++ , но ВЦ — презираю, лучше уж ЦБилдер...

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

DM>>Delphi всетаки предназначен для написания мелких и средних систем для работы в основном с БД. Соответственно на производстве он используется по назначению и написание сервисов отслеживающих чего-то там в большей степени исключение чем правило. А люди которые пишут клиентов на Дельфях в 90% случаях ламера.
HD>"Чушь... и плешь!" — Copyright (c) by Robert Hainlein (Чужак в чужой стране).
Сильный аргумент!!! :wow:
HD>Дельфи — это "RAD System — Rapid application Development System" т.е. система быстрой разработки приложений.
Удивительно! :super: И кто бы мог подумать. Еслиб вы мне этого не сказали я б и не узнал никогда.
HD>нигде не вижу слов про БД...
Ну Дэльфи ты наверное видел? Или ты о нем только слово RAD знаешь.
HD> странно... то, что они исхитрились встроить в систему быстрый удобный и универсальный движок работы с БД — честь им и хвала.
Хотелось бы мне узнать какую нишу на рынке занимал бы Дэльфи не сделай они этого. Не надо тешить себя надеждой, что в среде в которой ты пишешь и которой гордишся, есть еще что-то особенное.
HD>То, что я видел кучи прог написаных на VC в виде : берем сампл, чуть-чуть меняем, компиляем и выкладываем с криками, "что кул" и без необходимых библиотек, не значит, сто на VC одни придурки пишут. Исключения есть, везде и во всем. Терпимее надо быть...

Ну я думаю для тебя еще надо читать научиться. :user: Я вроде для непонятливых писал, что не имею ввиду всех Дэльфистов (лично для тебя готов сделать исключение), а только их большинство. Вобще привычка мыслить категорически присуща в основном малолеткам, идиотам и насколько я понимаю тебе. Далее в твоем стиле...

Извините за резкость, но накипело. Я привык, что мои собеседники стараются соблюдать определенные нормы приличия в разговоре со мной и не хамить. :down:

DM>>В определенных вещах ДА! Я имею ввиду конечно же не всех. Просто человек никогда не писавший на API, а только на MFC знает о "окнах" значительно меньше, чем API программера.
HD>Ох. Профессионал отличается от ламмера не знанием того, чем версия 4564.4534.324.3242 Сам-API лучше версии 4564.4534.324.3241, а также знанием 1,000,000 разных API, а тем, что решает задачу наиболее эффективным способом, заа наименьшее время и с максимальным соблюдением ее постановки.
Ну слава Господу нашему, что ты хоть это понимаешь. :super:
HD>Пример1:
HD>Если нужно сделать ОЧЕНЬ быстрый поиск в массиве целых чисел — он напишет реализацию на ассемблере
Флаг тебе в руки, барабан на шею и электричку на встречу!
HD>Пример2:
HD>Если нужно просто окно для ввода пароля — он возьмет Дельфы или Васик (но никак не ВС — там хотя бы компиляция дольше идти будет).
Спасибо тебе Господи, что он не стал писать его на асме. :maniac:

HD>Таким образом кричать, что: "Дельфы — ламмерская система!!!!!!!!!!!",
Я этого и не говорил (возвращаю тебя к букварю), а вот что ЛАМЕРОВ плодит в диком количестве, так ВЫ батенька тому пример. Это тебе ответ за ламера который следует чуть ниже по тексту.
HD> — потому, что аж завидки берут, как там просто и непринужденно можно писать достаточно мощные проекты, а вот на ВС приходится потеть
Ну в отличие от вас я не потею когда пишу код, не имею такой дурной привычки и не напрягаюсь сильно. СОВЕТ: применяй дезодарант Gillette Anti-Perspirant, должно помочь.
HD>- вы не проффессионал, извините, а натуральный ламмер (в крайнем случае, на продвинутого юзверя тянете :user: ).
Вот это конечно смело. :super: Я в ваших Борландах (читай Дэльфятинах) 3 года писал начиная еще с первой версии и сейчас иногда пописываю. В итоге полностью перебрался на VC, т.к. не люблю программировать интнрфейс, а любой др. код на VC получается быстрее. Да собственно, что греха таить на Дэльфи и простой интерфейс тормозит жутко, даром что разработка занимает меньше времени. А если вы батенька захотите разогнать его, то я сомневаюсь, что на API вы его быстрее напишите, чем на MFC. Давай не будем проверять, кто чего делал и кто в чем ЛАМЕР, результат тебе не понравится. Хотя я конечно не настолько самоуверенный придурок, чтоб не оставить тебе возможности на выигрышь. Еслиб вы, Hacker_Delphi, были меньшим ЛАМОМ, то наверняка зналиб, что рад системы применяются исключительно для разработок, мелких и средних систем и там их место. Ты когданить видел более менее серьездный интерфейс написанный на твоем любимом Дэльфи? Я не буду говорить о проблемах разработчиков (есть у меня знакомый один) пишущих их, но тормозят они страшно и сыпятся к томуже. :maniac: :crash:

HD>ЗЫ Извините за резкозть — накипело. да и надоело слушать, что все надо выкинуть нафиг — все надо писать на Ц++ а базы данных реализовывать самостоятельно.
Не прощу!!! Теперь мы квиты, но если хочешь... :))

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

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

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

Y>>>Там была формулировка — "крутую", я ее понял как "очень хорошую". Написание хорошого GUI — это очень весомы показатель, хороший GUI одинаково трудно создать и в Delphi и в VC.

DM>>Ну и совсем не правда! :) На VC сложнее. Хотел бы я посмотреть на реализацию комонента типа какого-то сложного контрола в исполнении среднестатистического дэльфиста на VC. :super:
HD>А я очень хотел бы увидеть исполнение СНОСНОГО, НО ПРАВИЛНО НАПИСАНОГО контрола для Дельфи написаного программером, всю жисть работавшим на Ц++ + МФЦ :))
Ну ты блин даешь. Что может быть проще написания не сложного контрола на API или ATL. А это все есть и в Дэльфи. Программер перебираясь из VC не по причине своей слабости как программист спокойно напишет такой контрол. А вот сможет, ли Дэльфист все время проработавший на какую-то фирмочку по продаже продуктов питания (а такие программеры и есть самые массовые среди Дэльфистов)использовать этот контрол, в этом я бы усомнился. :)

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

[skiped]

HD>Программистам на Ц++ тжко отучиться от макросов и отсутствия проверки приведений типов и прочих "прелестей" Ц++ (например, множественное наследование — это круто (а уж наскока глючно — слов нету

), но ни разу не сталкивался с тем, что это — необходимость.

Вообщем можно почти согласиться, если не мнодественное считать наследование интерфейсов.

HD>Так — пальцы загнуть), а вот возьми и выйди система, которая на Паскал`е (!!!) позволяет разработать не менее (а иногда — и более) эффективные программы под Виндовс...

Где ты такого наслушался? Ты хоть сам в это веришь?

HD>Плюс, остался предрассудок, что Паскаль ничего не умеет, хотя могу сказать точно: начиная версси этак с 6 (про седьмую — ваще молчу, ибо — КУУУЛЛЛ!!!!) вполне конкурентный язык.

Конкурентный? Если только с Васиком

Тут надо в корень зреть: для чего придумывался Паскаль (изначально, Виртом) и для чего С. И что из этого могло получиться.

На Паскале на описалово одних локальных переменных в отдельной секции нрвов потратишь большк, чем в С++ на множественное наследование. Про все остальное вообще молчу: все эти многословные then, begin, end, procedure, functon и т.п.

P.S. Почему-то все паскалисты везде кричат, что паскаль не уступает по возможностям С++ (где они такого наслушались :???

. Но почему-то я этой туфты ни разу не слышал из уст программиста на С++!

P.P.S. "Язык определяет способ нашего мышления и предопределяет, о чем мы можем думать". Б.В.Ворф

Так вот, Дельфи предопределила думать о Tкомпонентах, событиях, формах и т.п.

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

[skip]
HD>Дельфи — это "RAD System — Rapid application Development System" т.е. система быстрой разработки приложений. нигде не вижу слов про БД... странно... то, что они исхитрились встроить в систему быстрый удобный и универсальный движок работы с БД — честь им и хвала. То, что я видел кучи

Спорный вопрос... Особенно насчет удобный...

Более бессмысленного флейма я не видел уже давно. Все прогрессивное человечество уже давно перебралось на ассемблер, забыв об ужасах визуального программирования и прославляя WinAPI еженощно и ежеденно

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

A>Более бессмысленного флейма я не видел уже давно. Все прогрессивное человечество уже давно перебралось на ассемблер, забыв об ужасах визуального программирования и прославляя WinAPI еженощно и ежеденно :).

:)) :super:

.

Вот что бессмысленного это точно...

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

EB>TComponent обеспечивает манипулирование в design-time.
EB>Компоненты могут быть визуальными и невизуальными.
EB>Выгода компонентов -- кодирование заменяется на конструирование
EB>в design-time (не полностью, конечно). Чем меньше пишется кода,
EB>тем меньше делается ошибок.

А не если не писать код то ошибки не делаются? Это раз. А два: сейчас везде "кодирования" примерно поровну с "конструированием".

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

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

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

A>>>Радикально неверное мнение!

A>>>Т. е. Дельфы поддерживают и такое программирование тоже, но стричь всех, кто на них пишет, под одну гребенку — неверно.

DG>>Во-первых, я имел ввиду большую (но все таки не всю) часть дельфистов.
DG>>Во-вторых, если завтра взять двух достаточно умных людей, но которые не разбираются в программировании,
DG>>и посадим их писать проги на Delphi, и на VC, то второму придется (хошь, не хошь) выучить больше о программирование, чем первому.
HD>НЕ СОГЛАСЕН, абсолютно!!!
HD>Второй просто ничего сделать не смогет месяцев несколька, а первый — легко.

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

HD>Могу сказать, чт описать ГУИ на МФЦ — изврат, ибо библиотека дает крайне мало расширений к ГУИ. Мне, например проще реализовать все на ГУИ, чем разбираться с МФЦ (хотя я и ГУИ знаю и СиПП).

Мало расширений — тащи ActiveX. С MFC не так уж и сложно разбираться. Не сложнее, чем с VCL. VCL, правда, "площе" (мое скромное мнение).

HD>И вообще, сами ответы показывают какую-то нефилософскую предвзятость к Дельфи. А ответ, похоже, прост:
HD>Программистам на Ц++ тжко отучиться от макросов и отсутствия проверки приведений типов и прочих "прелестей" Ц++ (например, множественное наследование — это круто (а уж наскока глючно — слов нету

), но ни разу не сталкивался с тем, что это — необходимость. Так — пальцы загнуть), а вот возьми и выйди система, которая на Паскал`е (!!!) позволяет разработать не менее (а иногда — и более) эффективные программы под Виндовс...
HD>Плюс, остался предрассудок, что Паскаль ничего не умеет, хотя могу сказать точно: начиная версси этак с 6 (про седьмую — ваще молчу, ибо — КУУУЛЛЛ!!!!) вполне конкурентный язык.

Да, Паскаль почти ничего не умеет.

Бейсик и тот лучше.

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

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

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

Y>>>Я например совершенно не вижу разницы например при написании какого нибуть сервиса для отслеживания обращения к диску например. И в куче других задач, в большенстве задач, разницы не будет.....
DM>>Delphi всетаки предназначен для написания мелких и средних систем для работы в основном с БД. Соответственно на производстве он используется по назначению и написание сервисов отслеживающих чего-то там в большей степени исключение чем правило. А люди которые пишут клиентов на Дельфях в 90% случаях ламера.
HD>"Чушь... и плешь!" — Copyright (c) by Robert Hainlein (Чужак в чужой стране).

Robert Hainlein не мог такого написать: он на английском языке писал.

Будьте последовательны...

HD>Дельфи — это "RAD System — Rapid application Development System" т.е. система быстрой разработки приложений. нигде не вижу слов про БД... странно... то, что они исхитрились встроить в систему быстрый удобный и универсальный движок работы с БД — честь им и хвала. То, что я видел кучи прог написаных на VC в виде : берем сампл, чуть-чуть меняем, компиляем и выкладываем с криками, "что кул" и без необходимых библиотек, не значит, сто на VC одни придурки пишут. Исключения есть, везде и во всем. Терпимее надо быть...

Y>>>Или вы считатет что человек который пишет проект используя MCF например знает априори меньше чем человек пришуший на чистом API?

DM>>В определенных вещах ДА! Я имею ввиду конечно же не всех. Просто человек никогда не писавший на API, а только на MFC знает о "окнах" значительно меньше, чем API программера.
HD>Ох. Профессионал отличается от ламмера не знанием того, чем версия 4564.4534.324.3242 Сам-API лучше версии 4564.4534.324.3241, а также знанием 1,000,000 разных API, а тем, что решает задачу наиболее эффективным способом, заа наименьшее время и с максимальным соблюдением ее постановки.
HD>Пример1:
HD>Если нужно сделать ОЧЕНЬ быстрый поиск в массиве целых чисел — он напишет реализацию на ассемблере
HD>Пример2:
HD>Если нужно просто окно для ввода пароля — он возьмет Дельфы или Васик (но никак не ВС — там хотя бы компиляция дольше идти будет).
HD>Таким образом кричать, что: "Дельфы — ламмерская система!!!!!!!!!!!", — потому, что аж завидки берут, как там просто и непринужденно можно писать достаточно мощные проекты, а вот на ВС приходится потеть — вы не проффессионал, извините, а натуральный ламмер (в крайнем случае, на продвинутого юзверя тянете

).
HD>ЗЫ Извините за резкозть — накипело. да и надоело слушать, что все надо выкинуть нафиг — все надо писать на Ц++ а базы данных реализовывать самостоятельно.

Почему на C++? На Visual Basic, еще лучше — на VB.NET...

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

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

A>>Здравствуйте Ибрагим, Вы писали:

И>>>Но если профи в Win32 — этот чел однозначно не дельфист, а VCшник

A>>Враки! Лично я являюсь опровержением этих гнусных измышлений.
HD>Присоединяюсь. хоть и знаю Ц++ , но ВЦ — презираю, лучше уж ЦБилдер...

А Бейсик все равно лучше!

Здравствуйте Аноним, Вы писали:

А>Не берите в голову. Меня всегда удивляли люди, которые спрашивают не что я пишу, а на чем. IMHO какая разница на чем писать? Каждый пишет на том на чем удобнее. Я вот работал в одной конторке. Дык у них все продукты на Модуле2/Oberon2. И кстати отличные
А>языки программирования.

Готов поспорить.
Есть разница. Причем большая.
Был на фирме программер на Delphi.
Ушел оставив кучу глючного кода. Прихожу я со своим VC.
От паскаля помню только то что на первом курсе в обязаловку входило.
Результат. Делит весь его код на хрен и написал свой.

Вот в чем и разница. Наследование кода от программиста к программисту

А с нуля можно писать на чем хош. Выбор языка определяет поставленая задача.

Хотя компиляторы Borland неперевариваю. Что си, что билдер, что делфы.

А>Зы. Главное чтобы работа нравилась и было куда развиваться.

С досовского c++ сразу на mfc перескочил.
На Api как-то кроме hello World больше не че не написал

Так и прописал пол года проги в универе. Набивая карту сообщений ручками.
(MSDN, интернет, или вообще какой нить help отсутствовал )

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

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

E>>Другое странно, почему так много дельфистов идут в асмовские ряды?
E>>До сихз пор как психологу мне это не понятно.
E>>Тем более я замечаю (как уже говорил) некое нехорошее отличие в мышлении этих учеников...

Рек>Точно. Подтверждаю.
Рек>Большинство и моих знакомых увлечённых асмом, предпочитают Delphi.
Рек>Почему так? Это интересная психологическая задача.

Рек>Предположу.
Рек>Дело наверное в радости про которую писал Gosha.
Рек>Не радостное наверное это дело — писать на паскале...
Рек>Надёжно, удобно, эффективно.
Рек>Но не радостно.
Рек>

Из студенческого опыта.
1 семестр — ассемблер
2 семестр — паскаль
3 семестр — си
Когда перешли на паскаль большенство уже делало так

Procedure d()
begin

asm
{
}

end

Прошу прощения за синтаксис. Я паскаль уже забыл полностью Но смысл понятен.
После Ассемблера доканывает стройность типов.
Зато не надо долго и нужно писать интерфейс

V>Был на фирме программер на Delphi.
V>Ушел оставив кучу глючного кода. Прихожу я со своим VC.
V>От паскаля помню только то что на первом курсе в обязаловку входило.

И какой мы отсюда делаем вывод?

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

V>>Был на фирме программер на Delphi.
V>>Ушел оставив кучу глючного кода. Прихожу я со своим VC.
V>>От паскаля помню только то что на первом курсе в обязаловку входило.

IT>И какой мы отсюда делаем вывод?

Выучить делфы

В моем случае овчикна выделки не стоит.
На изучение VCL я потратил бы больше времени

V>>>Был на фирме программер на Delphi.
V>>>Ушел оставив кучу глючного кода. Прихожу я со своим VC.
V>>>От паскаля помню только то что на первом курсе в обязаловку входило.

IT>>И какой мы отсюда делаем вывод?

V>Выучить делфы

Не-е-е-т... Отсюда мы делаем два вывода:

1. Программер — козел (если код действительно глючный)

2. Важную роль играет возможность передачи кода на сопровождение и дописывание другому программеру. Упоминавшийся Oberon еще сложнее было бы передать. Интересно, опять-таки, как в этому аспекте будет обстоять дело с C#. Ведь многоязыковая поддержка .NET еще не избавляет от необходимости отладки чужого кода на чужом языке.

3. Никаких выводов о Delphi и Delphi-программерах сделать не могём

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

IT>2. Важную роль играет возможность передачи кода на сопровождение и дописывание другому программеру. Упоминавшийся Oberon еще сложнее было бы передать. Интересно, опять-таки, как в этому аспекте будет обстоять дело с C#. Ведь многоязыковая поддержка .NET еще не избавляет от необходимости отладки чужого кода на чужом языке.

Что то не нравится мне этот сенкувич.

Какая-то смесь бейсика и си.

IT>3. Никаких выводов о Delphi и Delphi-программерах сделать не могём

О программерах на делфи выводы и не делаем.
Выбор языка в идеале определяет поставленая задача.

Это был ответ на вопрос, почему спрашивают на чем ты пишеш.
Работодатели:
Поддержка кода

Народ.
А мож че полезное подскажеш

V>О программерах на делфи выводы и не делаем.
V>Выбор языка в идеале определяет поставленая задача.

Угу... вот только идеала в обозримой окрестности не наблюдается

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

A>>Враки! Лично я являюсь опровержением этих гнусных измышлений.
HD>Присоединяюсь. хоть и знаю Ц++ , но ВЦ — презираю, лучше уж ЦБилдер...

Зо что ж ты его презираешь?

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

IT>Если в Фоксе были элементы ООП,

IT>Нужны ещё основы COM, точнее даже не самого COM, а компонентного программирования. Без него сейчас никуда.

Вот уж без кома можно обойтись.

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

IT>>Нужны ещё основы COM, точнее даже не самого COM, а компонентного программирования. Без него сейчас никуда.

OLEG>Вот уж без кома можно обойтись.

После долгих сами знаете чего (в основном препирательств с "ценными" любителями Фортрана и VCL (only)), было таки принято решение не выпендриваться, а сделать все по-человечески: вся логика, система и все остальное- на VC, интерфейс — на Дельфях. А соединяет их — ... :)) По моему, к чему-то подобному в M$ и стремятся (правда, сейчас это зовется .NET)

З.Ы. Пусть старшие товарищи меня поправят

>система и все остальное- на VC, интерфейс — на Дельфях. А соединяет их — ...

По моему, к чему-то >подобному в M$ и стремятся (правда, сейчас это зовется .NET)

Хм... сомнительно... Почему решили интерфейс на дельфе делать? Потому что библиотека для этого удобна, компонентов море и проще все.

А .NET не только дает возможность работать на разных языках -она еще и ВЫНУЖДЕНА СДОРОВО СГЛАЖИВАТЬ РАЗЛИЧИЯ МЕЖДУ НИМИ. Система типов теперь одна, библиотека — одна и т.п.

Так что либо все будет хорошо и на любом языке будет удобно писать (ну разве что MC++ — ужас), либо... ...oops... на всех будет неудобно

Вот поздно я на эту тему наткнулся.
Эх, вот так пишешь на Дельфи 5 лет, а потом появляется какое-то... которое заявляет, что клиентов на Дельфи пишут ламеры, и по большому счету Дельфи не использует идеологию Документ-Представление... ну что за бред... Нормальный язык ООП... а Документ-Представление — это один из паттернов, бог знает почему выделенный MS и ужасно реализованный в MFC...
Насколько я понял, С++ крут не потому, что на нем можно смарт поинты создать или гомоморфное наследование использовать, а именно из-за того, что нужно писать GIU ручками, правильно? MS выбрал Си в качестве средства разработки, и поэтому Вы, уважаемые, ВЫНУЖДЕНЫ хвалить C++, ведь Вы используете API от MS... но не было ни одного восторга в этом топике в пользу С++ как мощного средства объектно-ориентированного программирования... Так получается, что С++ хорош только потому, что на нем Windows написан, а не сам по себе хорош...

Здравствуйте Аноним, Вы писали:

А>Вот поздно я на эту тему наткнулся.
А>Эх, вот так пишешь на Дельфи 5 лет, а потом появляется какое-то... которое заявляет, что клиентов на Дельфи пишут ламеры, и по большому счету Дельфи не использует идеологию Документ-Представление... ну что за бред... Нормальный язык ООП... а Документ-Представление — это один из паттернов, бог знает почему выделенный MS и ужасно реализованный в MFC...

Да так оно и есть.

А>Насколько я понял, С++ крут не потому, что на нем можно смарт поинты создать или гомоморфное наследование использовать, а именно из-за того, что нужно писать GIU ручками, правильно?

Хм. Наврядли. Это только в MSVC обязательно геморой иметь для того чтобы написать интерфейс, но достаточно даже на VC выбрать другую библиотеку и большую часть гемороя можно будет убрать, про BCB я вообще не говорю.

>MS выбрал Си в качестве средства разработки, и поэтому Вы, уважаемые, ВЫНУЖДЕНЫ хвалить C++, ведь Вы используете API от MS...

Дак кто его хвалит, он полное Г.

>но не было ни одного восторга в этом топике в пользу С++ как мощного средства объектно-ориентированного программирования...

Хм. Ява помоему гораздо блее можное средство в этом вопросе, но я восторгаюсь именно C++.

>Так получается, что С++ хорош только потому, что на нем Windows написан, а не сам по себе хорош...

Опять это не C++ хорош что на нем Windows написан а MSVC.

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

>>MS выбрал Си в качестве средства разработки, и поэтому Вы, уважаемые, ВЫНУЖДЕНЫ хвалить C++, ведь Вы используете API от MS...

A>Дак кто его хвалит, он полное Г.

Имеется ввиду WinAPI.

Здравствуйте Аноним, Вы писали:

A> но не было ни одного восторга в этом топике в пользу С++ как мощного средства объектно-ориентированного программирования...

Проблема в том, что C++ действительно не является мощным ООП языком (тот же C# на порядок удобнее), но C++ это просто мощный язык. А Delphi... Delphi(как язык) это просто один язык из многих, ему просто повезло, что за ним такая фирма как Borland.

Причем заметь, C++ — всем интересен даже просто как язык, без всяких там библиотек, VCL и т.д., а кому нужен Object Pascal? Кто о нем говорит? Он интерес только в контексте его окружения. А без этого окружения, как язык, он просто ноль.

Если же конечно сравнивать не языки, а языки + окружение, то для платформы Win я бы расставил так:

1. C#
2. Delphi
3. Builder
4. C++ + MFC
5. C++ + WTL/ATL

P.S. Если надо писать небольшие приложения, то я бы поставил связку C++ + WTL/ATL на 2 место.

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

DG>Если же конечно сравнивать не языки, а языки + окружение, то для платформы Win я бы расставил так:

DG>1. C#
DG>2. Delphi
DG>3. Builder
DG>4. C++ + MFC
DG>5. C++ + WTL/ATL

Я бы вот только BCB вынес на первое место т.к. он юзает и компоненты от Delphi и просто C++ либы.

На счет C# на первом месте — считаю что спорно, но спорить не буду.
И надо еще Java куда-нибудь воткнуть, куда-нибудь наверх, у них тоже очень хороший набор библиотек.

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

[skip]
A>Я бы вот только BCB вынес на первое место т.к. он юзает и компоненты от Delphi и просто C++ либы.

Вообще-то, среды нужно обязательно отделять от языков.
(Правда, пока это не относится к Delphi -- одна среда для одного языка).

Для C++ есть множество сред (IDE): С++Builder, Eclipse (будет портироваться), Sun Forte for C++, IBM VisualAge for C++ и т.д.
Для Java тоже: Borland JBuilder, Eclipse, netBeans, Sun Forte for Java, IBM VisualAge for Java, Symantec/WebGain VisualCafe и т.д.

A>На счет C# на первом месте — считаю что спорно, но спорить не буду.
A>И надо еще Java куда-нибудь воткнуть, куда-нибудь наверх, у них тоже очень хороший набор библиотек.

Куда ещё Java Вы хотите "воткнуть" (?) -- это независимый от устремлений MS язык!
Тогда, скорее, это будет Ваш собственный "ранжирный список".
Он всегда был "особняком" -- это платформа с чертами операционной системы ; операционная система для него всё равно что шашечки для такси.
(IMHO)

DG>>1. C#
DG>>2. Delphi
DG>>3. Builder
DG>>4. C++ + MFC
DG>>5. C++ + WTL/ATL
Да не хочу я спорить, что важней, авиация или кавалерия... мне за державу обидно... ну что плохого, если я, допустим, пишу базы на MSSQL, спроектировав их на Power Designer, делаю фасад данных на JBuilder, а клиента на Delphi? Ну получается так, что на клиента я обращаю меньше внимание, чем на бизнес-логику, и что из этого? и на супернавороченные контролы на клиенте начихать, вы уж извините меня за это...

Что же касается C++... когда на дельфи сервис NT пишу, то о скелете программы вообще практически не думаю, думаю, как у меня треды будут общаться. Хотя дело навыка, конечно...

Я хочу этим всем сказать, что лично я выбираю продукты в зависимости от важности отдельных частей программного комплекса. Зачем, скажем, тратить время на сокеты порта 80, если уже есть JSP??? Два щелчка мыши — и вы у цели... что, не круто? ну как угодно...
Кстати, о наборчиках и рейтингах. Писали бы уж рейтинги для конкретных жанров программ...
Я не занудлив?) например, для многозвенок
1. MSSQL+Delphi+MTS
2. Oracle+JDeveloper+Orion...
3....
4....
и т.д. и т.п.

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

[skip]
CL>После прочтения книжки про дельфи нашел одну интересную хозму (вот C++ программеры посмеются). Вызов чисто вируальных методов класса отслеживается не на этапе компиляции, а на этапе выполнения.

Это нащывается реализация полиморфизма в истинном(!) виде.
Такое было ущё в Borland Pascal 5.5 (первый промышленный ООП-Pascal).
Это есть в Java: единица компиляции -- класс, а не приложение (в принципе).
Очень странно и жаль, что многие сишники о таких вещах не знают и не задумываются (альтернатива есть!).
В C++ всё сделано ради скорости в ущерб гибкости.(IMHO)

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

A>Я бы вот только BCB вынес на первое место т.к. он юзает и компоненты от Delphi и просто C++ либы.

Проблема в том, что хоть в BCB по сравнению с Delphi есть плюсы (язык C++), так есть и большие минусы:
плохая поддержка стандарта C++,
вторичность по сравнению с Delphi (более поздний выход, больше глюков),
плохая оптимизация кода,

A>На счет C# на первом месте — считаю что спорно, но спорить не буду.

Но C# бесспорно лучше Delphi, вот C# и Delphi.Net будут равны, или даже Delphi.Net будет лучше (за счет своих классов), но правда к тому времени уже вторая версия шарпа выйдет.

A>И надо еще Java куда-нибудь воткнуть, куда-нибудь наверх, у них тоже очень хороший набор библиотек.

ИМХО, на Java-е мало пишут под винды....

Я полагаю, что Delhi — это вредный язык. Написать устойчиво работащую программу на Delhi нельзя по определению.
Вы только морочите голову заказчикам — Pascal разработан для обучения и только — студентами для студентов. На Pascal не пишут коммерческого софта. Это только обучение и Research.
А для обучения этот язык не годится начисто — возьмите лучше Python. Пусть медленно, но зато качественно.

A>Я полагаю, что Delhi — это вредный язык. Написать устойчиво работащую программу на Delhi нельзя по определению.

Господи, что за бред? Или "Delhi" — это что-то новенькое, о чем ученые не знают?

A>Вы только морочите голову заказчикам — Pascal разработан для обучения и только — студентами для студентов. На Pascal не пишут коммерческого софта. Это только обучение и Research.
A>А для обучения этот язык не годится начисто — возьмите лучше Python. Пусть медленно, но зато качественно.

Спасибо

Давно так не смеялся

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

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

A>>Я бы вот только BCB вынес на первое место т.к. он юзает и компоненты от Delphi и просто C++ либы.

DG>Проблема в том, что хоть в BCB по сравнению с Delphi есть плюсы (язык C++), так есть и большие минусы:
DG>плохая поддержка стандарта C++

Но поддержка стандарта C++ в ней гораздо лучше чем в Delphi

(Если серьезно то BCB более совместим со стандартом чем VC6)

DG>Но C# бесспорно лучше Delphi, вот C# и Delphi.Net будут равны, или даже Delphi.Net будет лучше (за счет своих классов), но правда к тому времени уже вторая версия шарпа выйдет.

Delphi.Net вышла почти месяц назад если ты не в курсе.

DG>ИМХО, на Java-е мало пишут под винды....

Хм. Извини что значит на Java пишут мало под винды, почти любая программа написаная на Java будет работать под винды.

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

A>Я полагаю, что Delhi — это вредный язык. Написать устойчиво работащую программу на Delhi нельзя по определению.

А помоему здесь дело в руках. Чем тебе TheBat например не нравится,
написан на Delphi.

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

A>(Если серьезно то BCB более совместим со стандартом чем VC6)

Не факт, насколько я помню, BCB очень не нравятся сложные вещи (хотя на простых он работает)

DG>>Но C# бесспорно лучше Delphi, вот C# и Delphi.Net будут равны, или даже Delphi.Net будет лучше (за счет своих классов), но правда к тому времени уже вторая версия шарпа выйдет.

A>Delphi.Net вышла почти месяц назад если ты не в курсе.

.Net пока в Delphi только для галочки.
Цитирую: "в поставку включены предварительная версия компилятора Delphi for .Net и RTL.Net (библиотека времени выполнения, ориентированная на работу с платформой .Net), позволяющая естественным образом работать с любыми классами .Net Framework, включая работу с ASP.Net. Затем возможно появится VCL.Net, после чего будет выпущен окончательный релиз, за которым и последует Delphi.Net (проект Gallileo)

Как видно из цитаты — пока есть только компилятор, а все остальное еще надо перенести на .Net.

DG>>ИМХО, на Java-е мало пишут под винды....

A>Хм. Извини что значит на Java пишут мало под винды, почти любая программа написаная на Java будет работать под винды.

Я хочу сказать, что если изначально стоит задача написать программу под Windows, то Java для этого едва ли будет использоваться.

A>А помоему здесь дело в руках. Чем тебе TheBat например не нравится,

Падает он, причем довольно часто. Особенно на Yahoo-шных RSDN-овских рассылках (когда пытается
проимпортировать или посмотреть письма), много и сложного html-я что ли ему не нравится?...

Каждому свое.
Кто-то любит апельсин, а кто-то тыкву.
Вряд ли стоит продолжать дальнейший разговор на тему Дельфи, уже было очень много реплик, которые явились для меня откровением об образованности их авторов. Питон так питон, VC++ так VC++, VB так VB... Бисер кончился.

P.S. Если что, Аноним в данной теме — это я.

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

IT>Господи, что за бред? Или "Delhi" — это что-то новенькое, о чем ученые не знают?

IT>Спасибо

Давно так не смеялся

Давайте разберемся.
Pascal был разработан для обучения программированию студентов. Студенты выросли, и считают, что Pascal это самый лучший язык программирования. Но это язык не для написания программ а обучения! Похожую картину я вижу и с Python. Разница только в том, что студенты, изучавшие Python слышали о С, на котором написан интерпритатор.
Вот откуда весь бардак.
Я не отицаю возможности макетирования программы на этапе проектирования на Pascal. Но удобнее это делать на интерпритируемом языке.
А вести спор что лучше C, Pascal, Python, или что-то еще — бессмысленно.

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

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

A>>(Если серьезно то BCB более совместим со стандартом чем VC6)

DG>Не факт, насколько я помню, BCB очень не нравятся сложные вещи (хотя на простых он работает)

А VC6 не нравятся даже простые. Нет VC6 не сравним с BCB5. (Утверждаю как человек с большим опытом и в том и в другом)

DG>Как видно из цитаты — пока есть только компилятор, а все остальное еще надо перенести на .Net.

Хм. Всех обманули называется. Надо посмотреть будет.

DG>Я хочу сказать, что если изначально стоит задача написать программу под Windows, то Java для этого едва ли будет использоваться.

Да нет вполне пишут. Даже у нас в фирме пишут иногда какие-нибудь внутренние тулзы на Java.

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

IT>>Спасибо

Давно так не смеялся

A>Pascal был разработан для обучения программированию студентов. Студенты выросли, и считают, что Pascal это самый лучший язык программирования. Но это язык не для написания программ а обучения!

Ты маленько путаешь Pascal который написал вирт и Pascal от Borland. В них различий больше чем общностей

> Похожую картину я вижу и с Python. Разница только в том, что студенты, изучавшие Python слышали о С, на котором написан интерпритатор.

Чего ты за питон схватился. Это скриптовый язык. Могу тебе сказать что он значительно лучше чем Perl, и очень сильно похож на Smalltalk, который все в свое время называли языком будущего, но как то у него не получилось.

Большие не Web проекты писать на Python можно, но не стоит.

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

A>>А помоему здесь дело в руках. Чем тебе TheBat например не нравится,

DG>Падает он, причем довольно часто. Особенно на Yahoo-шных RSDN-овских рассылках (когда пытается
DG>проимпортировать или посмотреть письма), много и сложного html-я что ли ему не нравится?...

Хм. У меня не падает, Outlook гораздо глючнее.

A>Хм. У меня не падает, Outlook гораздо глючнее.

Да, у меня тоже обычно не падает, но вот на Yahoo-шных рассылках — всегда валится, иногда из-за этого приходится "проблемное" письмо прямо на сервере убивать...

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

>Эх, вот так пишешь на Дельфи 5 лет,

Я 7 лет писал.

> а потом появляется какое-то... которое заявляет, что клиентов на Дельфи пишут ламеры, и по большому счету Дельфи не использует идеологию Документ-Представление... ну что за бред...

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

Я не занимаюсь Дельфи уже пару лет, и с удивлением стал последнее время обнаруживать пренебрежение к нему, мол на нем пишут только ламеры. На момент своего появления (94 если мне не изменяет память), это был писк моды. Потом, ввиду видимой легкости пролграммирования на нем малоопытными людьми большое количество тех самых малограмотных программеров выбрали его — как следствие большое количество поделок на нем. Что автоматически переносят на сам язык.

<<... J 1.0 alpha 5 >>

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

A>Delphi.Net вышла почти месяц назад если ты не в курсе.

Вышла Delphi 7 а не Delphi.NET

<<... J 1.0 alpha 5 >>

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

ZEN>Для C++ есть множество сред (IDE): С++Builder, Eclipse (будет портироваться), Sun Forte for C++, IBM VisualAge for C++ и т.д.
ZEN>Для Java тоже: Borland JBuilder, Eclipse, netBeans, Sun Forte for Java, IBM VisualAge for Java, Symantec/WebGain VisualCafe и т.д.

Не надо только с эклипсом путать. Либо считать его вышедшим еще рано, тогда его выбрасываем, оставляем вижуал эйдж, либо считаем что он вышел, тогда выкидываем вижуал эйдж.

<<... J 1.0 alpha 5 >>

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

DG>Падает он, причем довольно часто. Особенно на Yahoo-шных RSDN-овских рассылках (когда пытается
DG>проимпортировать или посмотреть письма), много и сложного html-я что ли ему не нравится?...

У меня вот не упал ни разу. Что я не так делаю?

<<... J 1.0 alpha 5 >>

Видите, ни одной работающей программы на Delphi не написали... Вы еще OS на Delphi предложите написать...

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

A>Большие не Web проекты писать на Python можно, но не стоит.

На Python писать софт я не предлагал. Я говорил о макетировании. Программы написанные на Python стабильно работать не будут по определению, как и на Pascal (Delphi), так и на BC. Я надеюсь, через несколько лет вы это поймете. Компиляторы по силам только разработчикам ОС.

DG>>Как видно из цитаты — пока есть только компилятор, а все остальное еще надо перенести на .Net.
A>Хм. Всех обманули называется. Надо посмотреть будет.

Кто тебя обманул? Они и не обещали полной поддержки .net в этом релизе. Вышедший продукт называется "Delphi 7", а не Delphi.Net

"... Я щас умру.. Газета называется "За передовую магию". Где здесь буква "К"?......"

A>На Python писать софт я не предлагал. Я говорил о макетировании. Программы написанные на Python стабильно работать не будут по определению, как и на Pascal (Delphi), так и на BC. Я надеюсь, через несколько лет вы это поймете. Компиляторы по силам только разработчикам ОС.

Может ты все-таки приведешь эти пресловутые "определения"? А мы обсудим... а? А то ведь какой-то полный бред пишешь.

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

хъ

S>P.S. Если что, Аноним в данной теме — это я.

это я тебе за это

Хорошо сказал.
Хороший программер не рассуждает о достоинствах или недостатках языка. Он их знает. И использует с максимальной выгодой. Нет совершенных вещей. Для каждой цели нужно выбирать наиболее подходящее средство.

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

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

A>>Большие не Web проекты писать на Python можно, но не стоит.

A>На Python писать софт я не предлагал. Я говорил о макетировании. Программы написанные на Python стабильно работать не будут по определению, как и на Pascal (Delphi), так и на BC. Я надеюсь, через несколько лет вы это поймете. Компиляторы по силам только разработчикам ОС.

Ну-ну. Если ты думаешь что компилятором в MS занимаются люди которые которые пишут OS то ты ошибаешься. Кроме того я бы не стал пользоваться компилятором который написали люди которые написали такую OS. У Windows такой API что гордится нечем.

Притом самые лучшие компиляторы C++ написали Intel и Comeau Computing, хорошие библиотеки написали Trolltech и Borland. А что такое хорошее MS сделала я вообще не видел.

Интересно, послушать те определения, согласно которым программы на вышеуказанных языках стабильно работать не будут — давай вообще поговорим о стадильности работы программ. Вот скажи что ты понимаешь под стабильностью работой программы и еще очень интересно какие языки позволяют писать стабильные программы

Голословия мы тут не потерпим

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

A>>Большие не Web проекты писать на Python можно, но не стоит.

A>На Python писать софт я не предлагал. Я говорил о макетировании. Программы написанные на Python стабильно работать не будут по определению, как и на Pascal (Delphi), так и на BC. Я надеюсь, через несколько лет вы это поймете. Компиляторы по силам только разработчикам ОС.

Не берусь лезть в высокую науку и тем более записываться в гуру, но IMHO, устойчивость (надежность) софта вообще никак не коррелируют с конкретным языком или еще чем. При желании драйвера можно и на VB писать

Кстати, в догонку. А написание ОС по силам только писателям компиляторов

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

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

>>Эх, вот так пишешь на Дельфи 5 лет,

AVK>Я 7 лет писал.

>> а потом появляется какое-то... которое заявляет, что клиентов на Дельфи пишут ламеры, и по большому счету Дельфи не использует идеологию Документ-Представление... ну что за бред...

AVK>Любой инструмент имеет свои сильные и слабые стороны.

Золотоые слова

AVK>Я не занимаюсь Дельфи уже пару лет, и с удивлением стал последнее время обнаруживать пренебрежение к нему, мол на нем пишут только ламеры. На момент своего появления (94 если мне не изменяет память), это был писк моды. Потом, ввиду видимой легкости пролграммирования на нем малоопытными людьми большое количество тех самых малограмотных программеров выбрали его — как следствие большое количество поделок на нем. Что автоматически переносят на сам язык.

Вообще в этом форуме была сказана неплохая мысль (автора не помню) : "...количество ламеров в процентах на Delphi выше...". По своему опыту могу сказать, что это недалеко от истины

(не в коей мере это не относится к авторам посланий). Писать логику (в смысле не UI) на Дельфях после C++ только под дулом или за огромные бабки

, а вот интерфейс или БД средней руки — на Delphi милое дело. Вот так.

З.Ы. Интересно, исчерпается когда нибудь эта тема? (Язык vs Язык)

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

EB>- Дельфи плохо подходит для больших проектов

EB>Скорее наоборот, Дельфи прекрасно подходит для больших проектов, т. к. Object Pascal -- язык более строгий и простой.
EB>Легче не допускать ощибки и отлавливать возникшие. Визуальэное проектирование тут уходит на второй план.

Хмм... я просто никогда не видел больших проектов на Дельфи. Вот у нас в конторе есть один проект на VC++, там примерно 140 мегабайт кода. Разделенного на несколько сотен модулей. Интересно, а Дельфи вообще справится с таким объемом?

EB>- Человек, пишущий на MFC учится большему, чем человек, пишущий на Дельфи
EB>MFC можно считать образцом того, как не надо писать библиотеки на C++. И чему же человек учится? Плохому стилю программирования на C++

Не совсем так. Человек, пишущий на Дельфи, привык писать так, как ему нравится. MFC (а особенно WinAPI) приучает писать так, как положено. Второе, конечно, сложнее... но зато и программа в результате работает так, как положено, а не как хочет

EB>- Язык Дельфи не дотягивает ни до С++, ни до Net.
EB>Вы просто не знаете язык Дельфи.
EB>А в Net многое откровенно слизано с Дельфи.

Вы просто не знаете язык C++.

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

SC> "...количество ламеров в процентах на Delphi выше...". По своему опыту могу сказать, что это недалеко от истины

Я все никак не въеду. Как "...количество ламеров в процентах на Delphi выше..." коррелирует с "Писать логику (в смысле не UI) на Дельфях после C++ только под дулом или за огромные бабки"?
А логику на Дельфи писали, да еще какую. Апп сервер к примеру устроит? И я не сказал бы что там это намного сложнее чем в С++. RTTI к примеру заметно мощнее.

<<... J 1.0 alpha 5 >>

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

EB>>- Язык Дельфи не дотягивает ни до С++, ни до Net.
EB>>Вы просто не знаете язык Дельфи.
EB>>А в Net многое откровенно слизано с Дельфи.

D>Вы просто не знаете язык C++.

Вы просто не знаете что такое дотнет. Винформсы куда ближе к VCL нежели к любой MSной либе.

<<... J 1.0 alpha 5 >>

AVK>Вы просто не знаете что такое дотнет. Винформсы куда ближе к VCL нежели к любой MSной либе.

Абсолютно согласен!
Я имею плохое представление о VB, может это Delphi похожа на него, но если не обращать на него внимания, то действительно, C# и WinForms — выглядят как навороченная и переделанная с нуля Delphi.

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

AVK>>Вы просто не знаете что такое дотнет. Винформсы куда ближе к VCL нежели к любой MSной либе.

IT>Абсолютно согласен!
IT>Я имею плохое представление о VB, может это Delphi похожа на него, но если не обращать на него внимания, то действительно, C# и WinForms — выглядят как навороченная и переделанная с нуля Delphi.

Учитывая что MS для написание C# сманила главного идеолога Delphi, было бы страннол если бы оно выглядело как-нибудь по другому

Здравствуйте:

IT>Может ты все-таки приведешь эти пресловутые "определения"? А мы обсудим... а? А то ведь какой-то полный бред пишешь.

Раньше я полагал, что Delhi — это вредный язык. Теперь Igor Trofimov изменил мое мнение на этот счет. Delhi — это полезный язык. Если С++ придумали для того чтобы неспециалисты не занимались программированием, до Delhi для того, чтобы неспециалистам было чем заняться и они поменьше морочили голову другим всякой ерундой.

И, специально для Игоря Трофимова:
Ни одна область знаний не дает ответ на вопрос «ПОЧЕМУ?». Дается только ответ на вопрос «КАК?». Это придумал не я.

AVK> Любой инструмент имеет свои сильные и слабые стороны.
small_cat> Золотые слова.
О сильных и слабых сторонах инструментов мы обычно узнаем из опыта работы с ними.

Igor Trofimov> Может ты все-таки приведешь эти пресловутые "определения"? А мы обсудим... а? А то ведь какой-то полный бред пишешь.
«По определению» это и значит из опыта работы.

A>Раньше я полагал, что Delhi — это вредный язык. Теперь Igor Trofimov изменил мое мнение на этот счет. Delhi — это полезный язык. Если С++ придумали для того чтобы неспециалисты не занимались программированием, до Delhi для того, чтобы неспециалистам было чем заняться и они поменьше морочили голову другим всякой ерундой.

Слушай, может все-таки расскажешь общественности — что же это за язык такой? Тут никто про него не слышал, как мне кажется...

A>И, специально для Игоря Трофимова:
A>Ни одна область знаний не дает ответ на вопрос «ПОЧЕМУ?». Дается только ответ на вопрос «КАК?». Это придумал не я.

Кто бы не придумал — это слишком мощное обобщение, а следовательно, неверное. Ну и контрпримеры привести можно... К тому же не всвязи с обсуждаемой темой.

A>Igor Trofimov> Может ты все-таки приведешь эти пресловутые "определения"? А мы обсудим... а? А то ведь какой-то полный бред пишешь.
A>«По определению» это и значит из опыта работы.

Очень интересные новости

)) Ну я в общем, так и предполагал

)) Все программы, которые ты писал на каком-то неизвестном Delhi оказались неработающими. Из этого (по твоей терминологии — "по определению") мы делаем вывод, что нельзя написать работающую программу. Класс!!!

Во-первых весьма странное определение "по-определению", а во-вторых, банальная логическая ошибка.

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

IT>Кто бы не придумал — это слишком мощное обобщение, а следовательно, неверное. Ну и контрпримеры привести можно... К тому же не всвязи с обсуждаемой темой.

Давай пример — рассмотрим, как одни почему рождают другие почему.
Обсуждаемая тема — Философия так что все в тему. Хоть программерская форма движения материи.

AA>>«По определению» это и значит из опыта работы.

IT>Очень интересные новости

)) Ну я в общем, так и предполагал

Нет, не все которые я писал, а все которые написаны, и делают что-то отличное от "Привет Мир".

IT>Во-первых весьма странное определение "по-определению", а во-вторых, банальная логическая ошибка.

Все знания людей накоплены из исключительно из опыта. Где тут логическая ошибка?

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

A>Нет, не все которые я писал, а все которые написаны, и делают что-то отличное от "Привет Мир".

Тебе уже The Bat! приводили в качестве примера. У меня на предприятии есть расчет зарплаты на sql, писанный на дельфи. И тоже неплохо работает и не глючит.

A>Все знания людей накоплены из исключительно из опыта. Где тут логическая ошибка?

Но не все знания людей накоплены из твоего опыта.

<<... J 1.0 alpha 5 >>

A>Давай пример — рассмотрим, как одни почему рождают другие почему.

Пример. Открываем любой учебник математики, читаем любую теорему. Это предмет обсуждения.
на вопрос "почему" следует ответ в виде доказательства — четкий, логичный и непротиворечивый.

IT>>Очень интересные новости

)) Ну я в общем, так и предполагал

A>Нет, не все которые я писал, а все которые написаны, и делают что-то отличное от "Привет Мир".

А ты видел все программы, которые написаны на Delhi? Ну ты монстр!!!!!

A>Все знания людей накоплены из исключительно из опыта. Где тут логическая ошибка?

Не все знания накоплены из опыта. В любом случае "по определению" — обычно люди не понимают под этим личный опыт

Логическая ошибка такая, что даже если из твоего опыта что-то следует, нельзя делать заключение о том, что так оно и есть на самом деле ныне и присно и во веки веков.
Личный опыт: Число 1 — нечетное, простое, 3 — нечетное, простое, 5 — нечетное, простое, 7 — нечетное, простое.
Неверный вывод — все нечетные числа — простые.

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

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

A>>Нет, не все которые я писал, а все которые написаны, и делают что-то отличное от "Привет Мир".

AVK>Тебе уже The Bat! приводили в качестве примера. У меня на предприятии есть расчет зарплаты на sql, писанный на дельфи. И тоже неплохо работает и не глючит.

Общество признало что глючит. Я им вообще не пользуюсь. А расчет зарплаты на SQL или на дельфи? Или я отстал и теперь дельфи называется новый SQL?

A>>Все знания людей накоплены из исключительно из опыта. Где тут логическая ошибка?

AVK>Но не все знания людей накоплены из твоего опыта.

Но отвечаю то я.

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

A>>Давай пример — рассмотрим, как одни почему рождают другие почему.

IT>Пример. Открываем любой учебник математики, читаем любую теорему. Это предмет обсуждения.
IT>на вопрос "почему" следует ответ в виде доказательства — четкий, логичный и непротиворечивый.

Это какие теоремы отвечают на вопрос почему?

A>>Все знания людей накоплены из исключительно из опыта. Где тут логическая ошибка?

IT>Не все знания накоплены из опыта.

Какие не из опыта?

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

A>Общество признало что глючит.

Не общество, а кто то один. У меня вот ни одного глюка за долгое время.

A> Я им вообще не пользуюсь.

Следовательно он кривой? И Дельфи кривая? Интересный вывод.

A> А расчет зарплаты на SQL или на дельфи? Или я отстал и теперь дельфи называется новый SQL?

Ага, на SQL. А тетки прям в консоли запросы долбят.

AVK>>Но не все знания людей накоплены из твоего опыта.

A>Но отвечаю то я.

То есть ты считаешь свой личный опыт единственным?

<<... J 1.0 alpha 5 >>

A>Это какие теоремы отвечают на вопрос почему?
Отвечают не теоремы, а доказательства.
Ладно, привожу пример, раз не видишь:
теорема: "В Евклидовой геометрии сумма углов треугольника равна 180 градусам".
Вопрос: ПОЧЕМУ?
ответ: <доказательство> ВОТ ПОЭТОМУ.

IT>>Не все знания накоплены из опыта.
A>Какие не из опыта?
А например те же, математические... являющиеся логическим следствием других знаний, выведенные аналитически...
Стивен Хокинг объяснил, ПОЧЕМУ черные дыры излучают. Это не был его личный опыт

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

IT>Логическая ошибка такая, что даже если из твоего опыта что-то следует, нельзя делать заключение о том, что так оно и есть на самом деле ныне и присно и во веки веков.
IT>Личный опыт: Число 1 — нечетное, простое, 3 — нечетное, простое, 5 — нечетное, простое, 7 — нечетное, простое.
IT>Неверный вывод — все нечетные числа — простые.

Забавный у вас личный опыт, с мат. индукцией вы видимо вообще не знакомы

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

A>Общество признало что глючит. Я им вообще не пользуюсь.

Забавная методика рассуждения, я попробую скопировать твой стиль:

А еще я один раз как-то давно написал программу на VC и она у меня взглючила. Наверное VC бажный и на нем вообще нельзя написать работающую программу

А еще за долго до этого когда я вообще не умел программировать я что-то пытался в нем набрать а оно вообще не скомпилировалось, ну как можно работать с таким Г

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

Вывод: на VC писать нельзя.

А вообще ты знаешь если ты утверждаешь что на Delphi нельзя чего-либо написать то объясни почему ты так считаешь?

Может быть у нее были неграмотные разработчики? тогда почему они сейчас пишут C# для Microsoft?

Может быть она генерирует неправильный код? Тогда покажи мне пример программы которая должна работать но не работает.

Может быть ты считаешь что раз операционную систему писали в MS то только они могут писать правильные программы, поскольку обладают "тайными знаниями". Тогда получается что ты плохой программист, поскольку ты не работаешь в MS.

Между прочим то что Delphi так долго держится на рынке не смотря на давление Microsoft, и очевидное преимущество Microsoft на этом рынке, говорит в ее пользу.

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

TAT>моё мнение что хороший програмист — назовём его профессионалом

Золотые слова.
На самом деле, мне мыслится, что большая половина из тех кто говорит, что тот кто пишет на Delphi(да не важно на чем) — не программер, сами таковыми не являются! Если программер действительно профессионал — он такого никогда не скажет!
Да есть такой момент, что на Delphi можно программить щелкая мышкой — это и развращает многих. НО это совершенно не значит, что так пишут все и что это правильно. Профессиональный программер всегда будет писать профессионально не важно на чем, не смотря на то, что есть куча возможностей просто клацать мышой.

TAT>это вам хобби или вы этим работаете ?

А если отвлечся вааще, то нужно просто определиться: если ты хочешь зарабатывать бабло, то действительно не имеет никакого значения то на чем ты пишешь, как ты пишешь и какая у тебя квалификация, если ты сумел сделать все быстро, подобрал средства оптимально и это уже работает, всех устраивает и все довольны — молодец! Я знаю кучу людей, которые имеют не большой кругозор в программировании и работают методом научного тыка и на авось и достигли многого... Ну так в чем смысл жизни? Пусть я буду 1000 раз не программер, пися

на Delphi, VB (или еще на чем), но если я добьюсь в жизни чего-то, каких-то определенных вершин ну так и отлично!

Здравствуйте Аноним, Вы писали:

А>Забавный у вас личный опыт, с мат. индукцией вы видимо вообще не знакомы

С чего вы взяли? Я тут вообще не при чем

Я лишь иллюстрирую ход мышления т-ща __Alexey. А что — ваш ЛИЧНЫЙ ОПЫТ не согласен с тем, что первые 4 нечетных натуральных числа — простые?

Наверное все-таки ваш личный опыт говорит о том же.

Воот.. А человек тут утверждает, что личный опыт — это
а) "по определению"
б) истина в последней инстанции

Отсюда и выходит, что все нечетные — простые по определению

Вот ведь бред-то какой....

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

HD>Программистам на Ц++ тжко отучиться от макросов и отсутствия проверки приведений типов и прочих "прелестей" Ц++ (например, множественное наследование — это круто (а уж наскока глючно — слов нету

), но ни разу не сталкивался с тем, что это — необходимость.

Вот тебе и твой уровень.

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

DS>Так вот, Дельфи предопределила думать о Tкомпонентах, событиях, формах и т.п.

А о шаблонах типов (template) они что нибудь слышали?
В этом отношении CBuilder хорош, но компилирует долго.

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

IT>Отсюда и выходит, что все нечетные — простые по определению

Если определить простоту как нечетность, то он прав.
Семантику слов можно тасовать при необходимости....

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

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

DG>Вдогонку...

S>>>По-вашему, чем вызвано такое негативное отношение?

DG>Если приходит человек и говорит, что написал GUI-программу на VC на WinApi (или даже на MFC), это значит что этот человек набрался хоть каких-то знаний о Windows,
DG>а если приходит человек и говорит, я тут сбацал крутую GUI-программу на Delphi, то это говорит только о том, что человек умеет держать мышку...

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

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

A>>Это какие теоремы отвечают на вопрос почему?
IT>Отвечают не теоремы, а доказательства.
IT>Ладно, привожу пример, раз не видишь:
IT>теорема: "В Евклидовой геометрии сумма углов треугольника равна 180 градусам".
IT>Вопрос: ПОЧЕМУ?
IT>ответ: <доказательство> ВОТ ПОЭТОМУ.

Не совсем так. Сумма углов треугольника равна 180 градусам по 2-м причинам —
1. Так устроен Мир (а почему мы не знаем).
2. Мы так договорились, что в круге 360 градусов.

=> Любое доказательство строится на аксиомах, а аксиомы мы берем из ОПЫТА.

А сама теорема отвечает на вопросы как.
Как узнать один угол треугольника, если известны два других, и т.д.

IT>>>Не все знания накоплены из опыта.
A>>Какие не из опыта?
IT>А например те же, математические... являющиеся логическим следствием других знаний, выведенные аналитически...
IT>Стивен Хокинг объяснил, ПОЧЕМУ черные дыры излучают. Это не был его личный опыт

Все математические знания накоплены из опыта. Стивен Хокинг объяснил, ПОЧЕМУ черные дыры излучают.
1. Он знал что черные дыры есть?
2. Он знал что они излучают?
Ответь мне почему они есть, так чтобы я снова не мог спросить ПОЧЕМУ?

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

IT>Здравствуйте Аноним, Вы писали:

А>>Забавный у вас личный опыт, с мат. индукцией вы видимо вообще не знакомы

IT>С чего вы взяли? Я тут вообще не при чем

IT>Я лишь иллюстрирую ход мышления т-ща __Alexey. А что — ваш ЛИЧНЫЙ ОПЫТ не согласен с тем, что первые 4 нечетных натуральных числа — простые?

Наверное все-таки ваш личный опыт говорит о том же.

Молодец! Все стрелки на меня а сам в кусты. Ты всегда так делаешь?

IT>Воот.. А человек тут утверждает, что личный опыт — это
IT>а) "по определению"
IT>б) истина в последней инстанции

Пункт a) не надо выдергивать слова из контекста, а то другие могут не понять.

Пункт б) ты сам придумал, нечего не меня стрелки переводить. Не надо придумывать то, чего я не писал. Это ведь уже не первый раз!

A>Не совсем так. Сумма углов треугольника равна 180 градусам по 2-м причинам —
A>1. Так устроен Мир (а почему мы не знаем).

Мир тут не при чем. Есть некоторая аксиоматрика (евклидова геометрия, в данном случае)
И в рамках этой аксиоматики может существовать неочевидное истинное утверждение.
На вопрос "почему" может ответить доказательство теоремы.
Вопрос "А почему так устроен мир" тут не возникает, поскольку к миру эта аксиоматика может иметь весьма слабое отношение.

=>> Любое доказательство строится на аксиомах, а аксиомы мы берем из ОПЫТА.
Не-а. Можем сконструировать любую систему аксиом, базирующуюся на совершенно абстрактных понятиях.

A>Все математические знания накоплены из опыта. Стивен Хокинг объяснил, ПОЧЕМУ черные дыры излучают.
A>1. Он знал что черные дыры есть?

не знал. В то время это была чистая математика.

A>2. Он знал что они излучают?

нет. Но были предпосылки. Ну и что?

A>Ответь мне почему они есть, так чтобы я снова не мог спросить ПОЧЕМУ?
Это проще на примере с треугольником — более абстрактно.

Спускаясь по цепочке "почему" ты доходишь до аксиомы. На вопрос "почему аксиома такая" ответ может не существовать. Мы так сказали и весь хрен до копейки.

Да и сам ИЗНАЧАЛЬНЫЙ вопрос — он ставится в рамках этой аксиоматики, так что ты дальше аксиомы и пойти-то "не имеешь права".

Прочитай еще раз как я сформулировал: "В ЕВКЛИДОВОЙ ГЕОМЕТРИИ сумма углов... etc."
На вопрос "почему В ЕВКЛИДОВОЙ ГЕОМЕТРИИ сумма углов... etc". Следует ответ-доказательство.
При этом вопрос "а почему ЕВКЛИДОВА ГЕОМЕТРИЯ ТАКАЯ-ТО и ТАКАЯ-ТО" уже оторван от исходного положения.
Исходное положение доказано неопровержимо и окончательно.

A>Молодец! Все стрелки на меня а сам в кусты. Ты всегда так делаешь?

Что значит — "в кусты"? Это не я выдвигал странные обобщения и определения "по определению"

A>Пункт a) не надо выдергивать слова из контекста, а то другие могут не понять.

Цитирую вместе с контекстом, чтобы уж все поняли.

>Igor Trofimov> Может ты все-таки приведешь эти пресловутые "определения"?
>«По определению» это и значит из опыта работы.

б) ты сам придумал, нечего не меня стрелки переводить. Не надо придумывать то, чего я не писал. Это ведь уже не первый раз!

Да как же нет?! Я придумал???? Я бы до такого не додумался!

"Программы на Delhi и Python кривые по определению, написать надежную нельзя" — это что — не четкое выражение мнения о "истине в последней инстанции"??

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

A>>Не совсем так. Сумма углов треугольника равна 180 градусам по 2-м причинам —
A>>1. Так устроен Мир (а почему мы не знаем).

IT>Мир тут не при чем. Есть некоторая аксиоматрика (евклидова геометрия, в данном случае)
IT>И в рамках этой аксиоматики может существовать неочевидное истинное утверждение.
IT>На вопрос "почему" может ответить доказательство теоремы.

IT>Вопрос "А почему так устроен мир" тут не возникает, поскольку к миру эта аксиоматика может иметь весьма слабое отношение.

Ну если мир не причем... То у меня не вопросов.

=>>> Любое доказательство строится на аксиомах, а аксиомы мы берем из ОПЫТА.
IT>Не-а. Можем сконструировать любую систему аксиом, базирующуюся на совершенно абстрактных понятиях.

Противоречишь сам себе.

A>>Все математические знания накоплены из опыта. Стивен Хокинг объяснил, ПОЧЕМУ черные дыры излучают.
A>>1. Он знал что черные дыры есть?

IT>не знал. В то время это была чистая математика.

A>>2. Он знал что они излучают?

IT>нет. Но были предпосылки. Ну и что?

A>>Ответь мне почему они есть, так чтобы я снова не мог спросить ПОЧЕМУ?
IT>Это проще на примере с треугольником — более абстрактно.

IT>Спускаясь по цепочке "почему" ты доходишь до аксиомы. На вопрос "почему аксиома такая" ответ может не существовать. Мы так сказали и весь хрен до копейки.

Рад что ты сам показал что ни одна наука не может ответь на вопрос Почему.

IT>Да и сам ИЗНАЧАЛЬНЫЙ вопрос — он ставится в рамках этой аксиоматики, так что ты дальше аксиомы и пойти-то "не имеешь права".

IT>Прочитай еще раз как я сформулировал: "В ЕВКЛИДОВОЙ ГЕОМЕТРИИ сумма углов... etc."
IT>На вопрос "почему В ЕВКЛИДОВОЙ ГЕОМЕТРИИ сумма углов... etc". Следует ответ-доказательство.
IT>При этом вопрос "а почему ЕВКЛИДОВА ГЕОМЕТРИЯ ТАКАЯ-ТО и ТАКАЯ-ТО" уже оторван от исходного положения.
IT>Исходное положение доказано неопровержимо и окончательно.

Ха-Ха.

Ну да ладно, это не главное. Главное что ты понял мою логику, а я твою.

Вернемся к теме ветки.
Итак, путь по аксиомам:
Аксиомы.
Разработчикам MS более хорошо известна их родная OS, нежели другим, особенно учитывая, что исходный код OS закрыт.
Разработчикам компилятора должна быть хорошо известна OS.
Разработчикам компилятора должна быть хорошо известно устройство процессора для которого делается код.
Процессоры, на которых работает MS Windows делает не только Intel.

Делаем вывод.
MS: хорошо известна OS и для них открыт исходный код OS.
Intel: хорошо известно устройство процессора.
Borland: не известно ни то ни другое.
Следовательно, разработчики MS и разработчики третьих компаний стоят не в равных условиях.

Я бы шел другим путем (чисто статистический подход):
Берем список наиболее популярного программного обеспечения, и считаем частоты встречаемости компиляторов разных фирм. Я думаю, не считая, несложно догадаться кто впереди.

Если брать не работоспособность программ, а только легкость написания кода (обучение студентов, (которые в силу своей специальности не должны писать OS и всякие драйверы), макетирование программ и научные изыскания) – то ситуация совсем другая. Первое место занимают интерпретируемые языки, поскольку, при их разработке делается упор на возможность легкого написания качественного кода. Тут знание OS и процессора не нужно, выполняется программа на виртуальной машине, которую придумали сами разработчики языка. Поэтому, я написал про Python. Я сам не очень люблю на нем писать, и полагаю что в нем слишком много не нужных заворотов, которые годятся только для обучения студентов, дабы те знали разные типы представления данных. Но, по своей статистике я вижу, что много очень грамотных и уважаемых мной людей используют именно его. Мне же гораздо ближе “компактные” языки (мало кода много толка), типа Lisp, или Паскалеподобный (это не мое мнение, мнение его разработчиков) Lua (www.lua.org).

Такая аргументация устраивает фанатов Delphi?

Считаю вопрос исчерпанным. Поставленные оценки считаю совершенно справедливыми.

Запрещается публиковать продолжения в эту ветку обсуждения "Мнение о Delphi"

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

S>Часто приходится слышать мнение, что разработчики, использующие delphi -
S>ваще не программисты, а так... детишки неразумные.
S>Ясно, что у нее (как и у каждого ср-ва разработки) есть свои минусы,
S>но и плюсы тоже имеются. Я, например, юзаю с равной интенсивностью и
S>delphi, и vc++, и MASM. И что, об этом лучше никому не говорить?
S>По-вашему, чем вызвано такое негативное отношение?

Object Pascal + VCL + RAD = ЗВЕРСКАЯ МНЕСЬ

Это не просто лучший язык — это лучшее творение, что могло прийти в голову человеку за все 8000 лет существования цивилизации!

Вы все, уважаемые, С++-ориентированные "гении" программирования просто как тузики идете в том направлении, куда ведет какая-то кем-то придуманная "мода". Если БИЛЛ_ГЕЙТС_&_MICROSOFT_CORP пишут на C++, то они пишут на нем только потому, что они на нем пишут! Выучив в свои 20 лет Билли не C++, а какую-нибудь другую штуку, все бы вы писали именно на ней — просто вы не имеете своего собственного мнения!!!

(хотя, тоже могу согласиться, что на ДЕЛФИ пишет большое число программеров ********, умеющих только кидать кнопки на форму, и считающих себя гениями! Просто на C++ таких нет, потому-что на Си надо еще ********* часика два, чтобы эту кнопку создать на этой же форме).

Но: я конечно не спорю, что компилятор Turbo-Pascal'я на много уступал компилятору Си (и то, так как он в отличии от Си++совского был полностью автоматическим и из-за этого компилировал всегда в одной модели и не поддерживал модель TINY для COM-файлов)!!!

Но этого нет в Object Pascal'е!!!
+ Компилятор ни чем не уступает СИшному, а даже компилирует быстрее!
+ Делфи ЭТО RAD — Чтобы создать диалоговое окно, надо просто поработать пять минут мышкой, а не ******* с ресурсами, а потом в ручную все это прописывать!
+ VCL — этого у Си++ никогда небыло (в отличие от Билдера, который с ним работает как колека)
+ СИНТАКСИС у ПАСКАЛЯ в отличие от СИ на много удобней (да и не только синтаксис, а и вся логика языка)!
— Один минус у ДЕЛФИ: Тупые STRING-строки, не поддерживаемые операционкой (оставшиеся со времен Никлауса Вирта). Да и то, Паскаль (в отличие от СИ) с ними может вытворять все, что угодно: как с числами.

От того, что упрощается процесс создания скелета приложения программы на ДЕЛФИ в отличие от СИ отличаются:
— стабильностью (т.к. большую часть кода в EXE вставляет компилятор, а не полуумный программист)
— привлекательным интерфейсом (я еще не видел ни одной проги с красивым интерфейсом на СИ: кроме ПО Microsoft и других фирм с многотысячной армией дизайнеров и стилистов)
— процесс создания прог на Делфи происходит на несколько порядков быстрее (пока СИ-программер введет только слово int PASCAL WinMain, ДЕЛФИ-разработчик уже накидает весь интерфейс).

Привет, ************!
Кто думает, что круче меня, Delphi-программиста, напишите: ksergeus@rambler.ru.
Готов даже заключить пари: кто на чем напишет программу быстрее, стабильней, приятней, функциональней!

P.S. Я, кстати, прекрасно пишу и на C++

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

<admin>
За плохое поведение Whistler внесён в банлист на месяц.
</admin>

Нда....

Типичный пример того, что фанат чего угодно — это всегда беда....

Хотя я тоже очень люблю Delphi, но зато я очень не люблю крайностей и обобщений.

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

W>- Один минус у ДЕЛФИ: Тупые STRING-строки, не поддерживаемые операционкой (оставшиеся со времен Никлауса Вирта). Да и то, Паскаль (в отличие от СИ) с ними может вытворять все, что угодно: как с числами.

Помимо многого прочего, ты еще и не знаешь, что в виртовом Паскале типа string как раз не было! Там были array [??..??] of char и только-то! И гемороишше был с ними ишшо тот!

Здравствуйте Аноним, Вы писали:

А>Помимо многого прочего, ты еще и не знаешь, что в виртовом Паскале типа string как раз не было! Там были array [??..??] of char и только-то! И гемороишше был с ними ишшо тот!

Хм. Нет, помоему те здесь не прав. Там строки всегда были.

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

A>Здравствуйте Аноним, Вы писали:

А>>Помимо многого прочего, ты еще и не знаешь, что в виртовом Паскале типа string как раз не было! Там были array [??..??] of char и только-то! И гемороишше был с ними ишшо тот!

A>Хм. Нет, помоему те здесь не прав. Там строки всегда были.

Нет, они появились только в Трупо-Паскале. До того существовала только возможность присвоения строкового литерала массиву из char.

program Strings;

type
  MyString = array[1..100] of char;

var
  s1     : array [1..100] of char;
  s2, s3 : array [1..100] of char;
  s4     : MyString;
  s5     : MyString;
  s6     : string; (* Тут ошибка - нема такого типу *)

begin
  s1 := 'Привет!'; (* Это можно, хвост заполняется пробелами *)
  s2 := s1; (* Ошибка: типы разные *)
  s3 := s2; (* Это можно: тип один и тот же, происходит копирование массива *)
  s4 := s1; (* Ошибка: типы разные *)
  s5 := s4; (* Это можно: тип один и тот же *)

  s2 := s2 + s3 (* Ошибка: нет такой операции "+" для массивов *)
end;

Здравствуйте Аноним, Вы писали:

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

W>>- Один минус у ДЕЛФИ: Тупые STRING-строки, не поддерживаемые операционкой (оставшиеся со времен Никлауса Вирта). Да и то, Паскаль (в отличие от СИ) с ними может вытворять все, что угодно: как с числами.

А>Помимо многого прочего, ты еще и не знаешь, что в виртовом Паскале типа string как раз не было! Там были array [??..??] of char и только-то! И гемороишше был с ними ишшо тот!

Помимо прочего вы ещё и не знаете что string строки давно уже не тупые, и отлично поддерживаются операционкой.

Я имею в виду AnsiString. Ведь ShortString давно уже никто не использует, не правда ли?

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

Z2>Здравствуйте Аноним, Вы писали:

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

W>>>- Один минус у ДЕЛФИ: Тупые STRING-строки, не поддерживаемые операционкой (оставшиеся со времен Никлауса Вирта). Да и то, Паскаль (в отличие от СИ) с ними может вытворять все, что угодно: как с числами.

А>>Помимо многого прочего, ты еще и не знаешь, что в виртовом Паскале типа string как раз не было! Там были array [??..??] of char и только-то! И гемороишше был с ними ишшо тот!

Z2>Помимо прочего вы ещё и не знаете что string строки давно уже не тупые, и отлично поддерживаются операционкой.

Я имею в виду AnsiString. Ведь ShortString давно уже никто не использует, не правда ли?

Во-первых, эта реплика относится к кому? И о чем она? Непонятно, есть ли в ней намерение с кем-то поспорить?

Во-вторых, что вообще имеется в виду, когда утверждается, что тип такой-то-сякой-то поддерживается операционкой? Это вообще странная формулировка. Вот например, поддерживает ли Windows тип int? А тип __int64? А __int128? В чем может заключаться такая поддержка? Поддержка строк, завершенных нулевым символом, в большинстве ОС имеется в том смысле, что такое соглашение о строках является частью значительного числа функций программного интерфейса. Поддержка строк BSTR имеется в Windows в виде функций Sys…. О какой такой поддержке строк AnsiString можно говорить, я не знаю, да и нужна ли им какая-то "поддержка"? Они и сами неплохо держатся.

Приводить тип string как довод о преимуществе Паскаля перед Си++ несколько странно, хотя бы потому что в Си++ такой тип тоже есть (хотя и не встроенный, но для чьих-то применений это может считаться преимуществом). Функциональность их в целом одинакова.

С другой стороны, многим приложениям не нужны строки в стиле Си, а если и нужны, то БП и ОП (но не виртов Паскаль) это дело тоже поддерживают.

А>Во-первых, эта реплика относится к кому? И о чем она? Непонятно, есть ли в ней намерение с кем-то поспорить?

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

.

А>Во-вторых, что вообще имеется в виду, когда утверждается, что тип такой-то-сякой-то поддерживается операционкой?

Под поддержкой я лично имел в виду то, что эти строки легко и непринуждённо передаются в WinAPIшные функции при помощи преобразования типов:
SomeWinAPIFunc(PChar(String1));
Судя по реплике первого оратора от него этот факт ускользнул.

А>Приводить тип string как довод о преимуществе Паскаля перед Си++ несколько странно, хотя бы потому что в Си++ такой тип тоже есть (хотя и не встроенный, но для чьих-то применений это может считаться преимуществом). Функциональность их в целом одинакова.

По-моему string был упомянут как раз в качестве недостатка Паскаля

А>С другой стороны, многим приложениям не нужны строки в стиле Си, а если и нужны, то БП и ОП (но не виртов Паскаль) это дело тоже поддерживают.

Ага-ага!

)
У одного рецепт этого блюда на английском , и у второго на французком. Как вы думаете, у кого курица получится вкуснее?

PS: Мне кажется, что споры про среды программирования сродни спору про курицу.

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

LD>Представим себе 2 поваров. Один из них пусть будет англичанином, второй французом. Пусть они оба готовят курицу. (Че-то есть захотелось

)
LD>У одного рецепт этого блюда на английском , и у второго на французком. Как вы думаете, у кого курица получится вкуснее?

LD>PS: Мне кажется, что споры про среды программирования сродни спору про курицу.

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

... << Янус 1.0 alpha 10 (developer build) >>

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

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

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

Но это уже будут не то.

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

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

DG>
DG>Можно развить и аналогию с языками...
DG>Допустим во французском языке нет слова "курица" или слова "микроволновка", тогда не понятно как сможет французский повар прочитать рецепт про приготовление курицы в это самой микроволновке.

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

DG>Но это уже будут не то.

А как быть, если во французском нет слова "микроволновка", а в ангельском — "курица"?

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

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

W>Привет, ************!
W>Кто думает, что круче меня, Delphi-программиста, напишите: ksergeus@rambler.ru.
W>Готов даже заключить пари: кто на чем напишет программу быстрее, стабильней, приятней, функциональней!

Чего на мои письма не отвечаешь, ******* фигов? Что слабо на моих условиях соревноваться?

Давай сравнивать, если хочешь я условия повторю, могу прям здесь. Судя по тону я так понимаю ты на любые условия согласен. Может хоть после этого поймешь, что такое Delphi и где его место. Причем место совсем не позорное и мной уважаемое, но есть целый класс задач в которых он ***** и ****** будет во веки вечные у ненавистного тебе VC++. Взяли манеру над сишниками издеваться глядя на обиженных BC++'ев.

W>P.S. Я, кстати, прекрасно пишу и на C++

Понтующийся ********!!!

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

DM>Чего на мои письма не отвечаешь, ******* фигов? Что слабо на моих условиях соревноваться?

Я вижу ты тоже в банлист захотел? Могу устроить.

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

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

DS>На Паскале на описалово одних локальных переменных в отдельной секции нрвов потратишь большк, чем в С++ на множественное наследование. Про все остальное вообще молчу: все эти многословные then, begin, end, procedure, functon и т.п.

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

Если уж на то пошло, то нелюбимый тобой VB имеет почти идельную схему выделения блока кода. В нем просто нет ни скобок, ни мегинов:

If bSome <> 0 Then
  SomeWork
End If

Заметь, на С++ пришлось бы или добавлять лишнюю строку или оставлять первую скобку на строке с ифом. Второе просто хуже читается и делает неудобным пользование функции перехода по скобке в (Секд + [). Прим закрывающий элемент явно указывает что он закрывает блок if, а не другой находящийся по соседству.

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

Паскль обделен такими сдедствами упрощения работы как шаблоны, макросы и множественное наследование. Но без них можно жить и даже создавать очень эффективные программы. В томже пращуне С++ языке С небыло ни шаблонов, ни множественного наследования, ни даже хоть какого нибудь наследования и тем не менее и сегодня на нем можно писать код скоростные характеристики которого близки к максимуму. В конечном итоге намного больше зависит от рук/головы программиста и от качества проектирования.

DS>P.S. Почему-то все паскалисты везде кричат, что паскаль не уступает по возможностям С++ (где они такого наслушались :???

. Но почему-то я этой туфты ни разу не слышал из уст программиста на С++!

Ну, вот я себя считаю в большей части сишником, но могу подтвердить, что на Паскале можно саздавать программы ничем не уступающие С++-ым. Просто иногда это делается намного сложенее чем на С++, а иногда намного проще. Возможности определяются двумя вещами: знаниями программиста и начальным базисом. Дельфи дает фору с точки зрения базиса (компоненты, рад среду, ...), но для получения качественного продукта нужен еще и программист с высокой квалификацией.

DS>P.P.S. "Язык определяет способ нашего мышления и предопределяет, о чем мы можем думать". Б.В.Ворф

Глупейшее высказывание. Особенно в отношении к языкам программирования.

Высоко-квалифицированный программист скорее будет выбирать язык под задачу. И уж точно ен будет думать в терминах С++ или Паскаля. Я язык средство выражения мыслей. Нужен для формулирования алгоритмов (или просто мыслей в случае обычного языка) для себя, ну и в целях транспрортного протокола

.

DS>Так вот, Дельфи предопределила думать о Tкомпонентах, событиях, формах и т.п.

Да тебя зазомбировали.

Где в Дельфи написано что нужно всегда искать нужный компонент, а не написать дцать строчке кода? Все дел лишь в том что простота Дельфи и VB сплатила вокруг этих RAD-сред большие армии ламеров. В мире Дельфи и VB есть много высоко-классных специалистов, просто их не видно за толпами бездорей и начинающих.

PS

Поодбные ветки ничего кроме флэйма не дают я уже пытался отвечать на подобный впрос Отличие Visual C++ от Builder C++.

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

DM>Ну и совсем не правда!

Ну гляди здесь. Все наши программисты от трех до семи лет отработали на паскале. Кода было решено делать компоненты, пересели на VC. Половина С++ знала еще до ОПаскля... кое кто изучал С++ как второй язык. На сегодня такого бреда как здесь от них не услышишь. Только здравые оценки что удобно там, что там.

ЗЫ

После сторого яязка все остальные уже не вызывают таких эмоций... ну еще один синтаксический изыск... ну еще один рантайм. В том же VC есть несклько рантайм подсистем программирование под которых требует совершенно разных знаний. Так создавать десктоп приложение и на MFC совсем не тоже самое, что делать ActiveX-компоненты, ну а писать сервисы не похоже не на первое не не второе.

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

DG>Если вызовем трех людей, дадим одному полотно, второму болгарку, а третьему автоген — и они все в троем разрежут рельс, то профи скорее всего первый.

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

Профи будет тот, кто спросит о дополнительных условиях.

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

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

DG>Но оба этих человека — полный профаны в выборе наиболее адекватных средств программирования под конкретные задачи.

Думаю что они все это делали 4fun.

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

DG>Delphi и VB — идеально подходят только для быстрого накидывания интерфейса, Delphi — также подходит для быстрого накидывания интерфейса для работы с БД.

И много ты на этих средах продуктов создал?

DG>Серьезные вещи на Delphi — писать не удобно.

Демогогия.

Корпоративный софт вещь очень серьезная, а писть его на этих продуктах давольно удобно, быстро и надежно. С++ здесь и рядом не стаял, даже если брать Билдер.

DG>минусы:
DG>1. Это наличие своего языка, который не совместим с С, поэтому все библиотеки (которые в большинстве C-шные) надо руками (что в конечном итоге лишнии время и лишние деньги) конвертить в Dephi.

Для многих предметных областей (о БД ты уже говорил сам) создано море оберток и компонентов, так что тезис верный, но несущественных во многих случаях.

DG>2. Слабая (вернее полное отсутствие) поддержка какой-либо идеологии данные/представление

Глупость краничащая с демогогией. У языков программирования вообще нет "идеологий данные/представление". Это всего лишь подход к решению локальной задачи "отображения данных и взаимодействия с пользователем". Что косается технологии отображения данных и обеспечения пользователького интерфейса Дельфи и VB проектировались в расчете на компонентное програмирование (чего нельзя сказать о С++) и на них легко реализуются модель данные/представление. Просто в этих языках в качестве источников данных выступают одни компоненты, а в представление обеспечивается другими (называемыми контролами). Вот и все. Эта модель куда богаче и продуктивнее того что предлагается в MFC. По сути MS сам выбрал стророну компонентов и конролов (VS.NET, C#, ...), а MFC видимо скоро перейдет в разряд легаси.

DG>3. Малая доля общего рынка, и совсем ничтожная доля рынка серьзных продуктов

Ты как-то со стравнения сред преешел на языки... если сравнивать Дельфи и VC++, то объем продаж у итих продуктов думаю схож.

VB в мире вообще является лидером в желтой мйке и к нему подбираются разные Явы. Это не более чем заблуждение. Темболее что глюков хватает во всех средствах разработки. Я не раз вылетал и в Дельяи и в VC. А сообщение о внутренней ошибке компиялтора я получал и на Intel C++ и на gcc, о VC я просто и говорить не хочу.

DG>, отсюда отсутствие каких-либо уже существующих наработок

Ты явно не владеешь информацией. Основной рынок повторно используемого кода — это компоненты. А там королями являются как раз VB и Дельфи. В ближайшее время только .NET сможет их переплюнуть.

DG> на рынке и "сырость" стандартных средсв.

Чистая демогогия. Даже коментировать не хочется.

DG>4. Серьезное оставание от Windows "mainstream"-а.

Ну, ты бы купил ради хожмы диск с 6-й (полгода, а то и год назад) и 7-й версий дельфи и посмотрел. Думаю тебя неприяно проразило бы то, что все новомодные течения в Дельфи попадают на пол года раньше чем в продукты MS. Если это навороты от самой MS, то паксимум через пол года после их появления. В зять хотя бы те же Веб-сервисы...

DG>5. Слабая интегрированность в Windows "mainstream"

А это еще что за зверь?

DG>Вот это очень серьезные стратегические минусы, которые надо принимать во внимание, при выборе в качестве разработки Delphi.

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

Здравствуйте Ибрагим, Вы писали:

И>Загляти в толковый словарь для начала. При чем здесь результаты ?

Дык без результатов тебя живо выпрут, а на твое место возьмут этого самого проффи.

Хотя ввообще то это все лингвистический спро, то о чем вы говорите называется специалист или асс.

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

HD>А я очень хотел бы увидеть исполнение СНОСНОГО, НО ПРАВИЛНО НАПИСАНОГО контрола для Дельфи написаного программером, всю жисть работавшим на Ц++ + МФЦ

См. здесь оснавная масса программистов в те времена переползала на Дельфи с VC.

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

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

Y>>И еще о Дельфи — идея VCL сама по себе замечательная, язык Object Pascal — тоже имеет мало недостатков.

IT>Всё, нет больше Object Pascal'я, Борланд переименовала его в язык Delphi.

Это ты так прикалываешся?

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

IT>...C... MSDN...Рихтер...COM, точнее даже не самого COM, а компонентного программирования. Без него сейчас никуда.

Здорово! Вот только я IT здесь не узнаю... А кде же: .NET, GC, C#, ...

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

IT>Так что либо все будет хорошо и на любом языке будет удобно писать (ну разве что MC++ — ужас), либо... ...oops... на всех будет неудобно
IT>

Да и на MC++ писать можно. Только выгоден он становится при условии что нужно с API-ями взаимодействовать или легаси под .NET причесывать.

Здравствуйте m.a.g., Вы писали:

MAG>По-моему, код на Basic немногим отличается.

Ну ты еще работу с конекшонами добавь...

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

IT>>Всё, нет больше Object Pascal'я, Борланд переименовала его в язык Delphi.

VD>Это ты так прикалываешся?

Не, это было где-то в официальной документации Borland на Kylix. Object Pascal от ныне будет именоваться Delphi и вся документация будет соответственно приведена в порядок.

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

IT>>...C... MSDN...Рихтер...COM, точнее даже не самого COM, а компонентного программирования. Без него сейчас никуда.

VD>Здорово! Вот только я IT здесь не узнаю... А кде же: .NET, GC, C#, ...

Come on, man!!!

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

muh>) Весьма прелюбопытное по архитектуре зрелище должно быть будет

Особенно учитывая то, что ребята из Бормана, похоже, как и МС, без серъезных огрехов работать все-таки не могут

Все элементарно... Будет язык с бегинами вместо фигурных скобок и оперетором := вместо += для назначения событий. Будет поддерживать винформсы и разные асп.нет-ы с веб-сервисами. Из изюминок обещают портацию VCL приложений. Т.е. пишут обертки для VCL-я.

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

Бета компилятрора шла с бэтой Дельфи 7, так что уже скоро мы увидим Дельфи.Нет.

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

DS>>...большинство, но, естессно, не все Дельфи-программисты, являются пользователями интересненького 2графического редактора" ( (с) по-моему IT

).

IT>Это не я. Это было монументальное произведение Влада — http://rsdn.ru/forum/?mid=3762

На прямую я такого вроде не говорил.

Но все же приятно что хоть одно мое произведение называеют монументальным.

PS

Особенно приятно становится просле того как посмотришь что там творится с орфографией.

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

AS>Напремер. С чего начинает програмист Дельфи — КАК ПРАВИЛО с разработки интерфейса. А с чего начинает программист на С++ — КАК ПРАВИЛО с разработки структуры классов и модулей.

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

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

Ничего страшного. Пока проект мал визуальность спосает. А когда он разрастается то приходит пора поделить все на классы и компоненты. Сделать так сказать редизайн. Хотя конечно если заранее известно что делается долгоживущий большой проект, то лучше сразу заняться проектированием. На этом много денег можно с экономить.

AS>По моему личному мнению Дельфи подходит для написания небольших проектов, не требующих длительного развития (эволюционирования).

Дык проще же применять с самого начала подходы Буча и Ко. И не важно что это дельфи, С++ или VB с C#-ом.

AS>А вот разрабатывать "долгосрочные" проекты я бы не стал.

Забавно, ты сам заговорил о стиле, а в конце слил все снова на среду и язык.

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

EB>Одним из главным аргументов в польэу Net, служит быстрота и ПРОСТОТА разработки на нем. Эти же аргументы приводят в качестве недостатком Дельфи. Остается только удивляться такой ненормальной логике.

Обычно люди плохо относящиеся к Дельфи плохо относятся и к дотнету.

EB>Дельфи дает простоту и скорость, причем сделано это уже давно, причем сочетается с быстротой вып-я программы, т. к. Дельфи делает настоящие экзешки. И вот теперь, через 6 лет, MS преподносит свое "открытие", которое даже не не компилирует в exe и требует огромных системных ресурсов.

Вот здесь ты допустил сразу три ошибки:

1. "MS преподносит свое "открытие" "

MS не изобретал промежуточный код. Если ты помнишь такой код поначалу нразывался П-код. Не дагадываешся почему.

Именно Паскль-код. MS просто создала лучший в мире Jit-компилятор для пи-кода.

2. "которое даже не не компилирует в exe" это похоже глупость вылетвшая по контексту. Думаю тебе не нужно обяснять, что и длл-и и exe .NET делает в вучшем виде.

3. "огромных системных ресурсов" в наших тестах производительности длельфи ни разу не получила реального приимущества над .NET. Причем за частую она даже отставала от Шарпа. Единственное чем отличаются приложение сделанное на Шарпе и на Дельфи, это тем что первое значительно медленнее загружается (так как в это момент происходить компиляция в машинный код и иде загрузка рантайма).

Теперь по существу. Нэт действительно любит больше память чем Дельфи, но объясняется это не пи-кодом, а тем что памятью в Нэте управляет GC. GC более ресурсоемок чем обычные хипы, но за то он упрощает программирование и радикально снижает вероятность появления критических ошибок. Вот тут то Дельфи проигрывает по полной программе.

К тому же Нэт превосходит Дельфи еще и в обеме функционала реализованного в стандартных библиотеках. VCL — это аналог WinForms, а WinForms это только малая толика от того объема и разнообразия билблиотек входящих в .NET Framework.

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

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

Рек>>Предположу.
Рек>>Дело наверное в радости про которую писал Gosha.
Рек>>Не радостное наверное это дело — писать на паскале...
Рек>>Надёжно, удобно, эффективно.
Рек>>Но не радостно.
Рек>>

Особенно радует слово "наверное", т.е. значит Рек точно на Паскале не писал.

Рек>Торгует мужик на базаре надувными шариками.
Рек>- Сколько стоят шарики? — спрашивают его.
Рек>- Рупь, — говорит, — только вы их не покупайте, они бракованные.
Рек>- Что? Не надуваются?
Рек>- Не. Надуваются, ещё как надуваются!.
Рек>- Что тогда? Лопаются?
Рек>- Неа. Не лопаются.
Рек>- А чтоже тогда?
Рек>Мужик тяжело вздышает и говорит
Рек>- Не радуют...

Этот анекдот я слышал в немного другой вариации и она мне нравится больше:

Граждане! Будьте предельно осторожны! В магазины города поступили поддельные ёлочные игрушки. С виду они ничем не отличаются от настоящих, но радости от них никакой.

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

A>«По определению» это и значит из опыта работы.

Я плякал...

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

A>Нет, не все которые я писал, а все которые написаны, и делают что-то отличное от "Привет Мир".

Интересно ты не понял на что Igor Trofimov тебе намекал? Мне кажется о горил том что главное слово здесь "ты". Извини но просто так смешно все это... не удержался.

A>Все знания людей накоплены из исключительно из опыта. Где тут логическая ошибка?

Да? А ты что нибудь о таких вещах как ядерная реакция, ну или таблица менделеева слышал? Твое завяление вообще отрицает полезность мозгов как токовых.

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

A>...

Согласен со все сказанноым выше... но

A>не смотря на давление Microsoft

это же просто бред! Ты что Борланд у Microsoft в красную книгу занесен. Таких ценных зверей как маленькие конкуренты отстреливать нельщзя!

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

A>>Все знания людей накоплены из исключительно из опыта. Где тут логическая ошибка?

VD>Да? А ты что нибудь о таких вещах как ядерная реакция, ну или таблица менделеева слышал? Твое завяление вообще отрицает полезность мозгов как токовых.

Этот топик надо перепихнуть в хумор.

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

A>...

A>...

A>Вывод: на VC писать нельзя.

В хумор однозначно!!!

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

VD>Хотя ввообще то это все лингвистический спро, то о чем вы говорите называется специалист или асс.

Асс это по английски задница. Тот о ком ты говоришь пишется просто ас, с одной с.

... << Янус 1.0 alpha 10 (developer build)>>

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

VD>MS не изобретал промежуточный код. Если ты помнишь такой код поначалу нразывался П-код. Не дагадываешся почему.

Именно Паскль-код.

Pseudo-code. Хотя смысл от этого не меняется конечно.

... << Янус 1.0 alpha 10 (developer build)>>

DG>>Delphi и VB — идеально подходят только для быстрого накидывания интерфейса, Delphi — также подходит для быстрого накидывания интерфейса для работы с БД.

VD>И много ты на этих средах продуктов создал?

Достаточно, чтобы высказывать свое мнение об этих продуктах.
На Дельфи — 4 коммерческих проекта, на Бейсике, каюсь, только один, но этого мне хватило с головой.

DG>> на рынке и "сырость" стандартных средсв.

VD>Чистая демогогия. Даже коментировать не хочется.

К сожалению, это личный опыт, когда вставляешь стандартный компонент от Борланда, начинаешь его чуть усиленнее использовать и он начинает падать (таким, например, был компонент для Ftp-соединения, если предыдущее соединение завершалось ошибкой, то повторное соединение приводило к Access Violation)

DG>>4. Серьезное оставание от Windows "mainstream"-а.

VD>Ну, ты бы купил ради хожмы диск с 6-й (полгода, а то и год назад) и 7-й версий дельфи и посмотрел. Думаю тебя неприяно проразило бы то, что все новомодные течения в Дельфи попадают на пол года раньше чем в продукты MS. Если это навороты от самой MS, то паксимум через пол года после их появления. В зять хотя бы те же Веб-сервисы...

Ну и? Взять тот же .Net, Microsoft-ская финальная версия вышла полгода назад, а Delphi только через полгода как-то впихал в себя .Net, а полная поддержка появится не раньше чем через год, полтора. То же самое было с поддержкой Win2K, WinXP...

Через сколько времени появилась поддержка Gdi++? на сколько она была удобна? через сколько времени появляется обертка над новой версией DirectX-а?

DG>>5. Слабая интегрированность в Windows "mainstream"

VD>А это еще что за зверь?

Это то, что моду на рынке Windows диктует Microsoft, а Дельфи находится в роли догоняющего.
Хотя бы такой банальный факт, о наличии стандартных библиотек, для VC и VB они сразу идут с Windows-ом.

VD>Да это просто незнание предмета спрора, и попытки доказать свою правоту любой ценой. Да некоторые доводы разумны, но не так критичны, а остальные просто явлются плодом ксенофобии.

Влад, а без наездов тебе спорить слабо? или слов и фактов не хватает и остается только сказать "Сам дурак"...

VD>И много ты на этих средах продуктов создал?

Встречный вопрос, а сколько ты создал продуктов на данных средах?

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

DG>Встречный вопрос, а сколько ты создал продуктов на данных средах?

Я писал на Дельфи, причем довольно много. То что он сказал в общем то совершенно верно.

... << Янус 1.0 alpha 10 (developer build)>>

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

DG>К сожалению, это личный опыт, когда вставляешь стандартный компонент от Борланда, начинаешь его чуть усиленнее использовать и он начинает падать (таким, например, был компонент для Ftp-соединения, если предыдущее соединение завершалось ошибкой, то повторное соединение приводило к Access Violation)

Как будто в МСных компонентах глюков нет.

... << Янус 1.0 alpha 10 (developer build)>>

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

VD>Особенно приятно становится просле того как посмотришь что там творится с орфографией.

Оно еще войдет в учебники русского языка!

Как пример: вот, деточки, как непонятно можно выразить простые и ясные мысли, если не научиться ставить запятые!

VD>Ну тут тебе могут возразить что многим фигурные скобки кажутся очень неудобными, а бегин с этдом очень даже. Это просто дело вкуса. На качестве языка это не сильно сказывается.

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

Это смотря какой стороны сие явление рассматривать. Я вот слепым методом набираю, так по мне begin\end гораздо удобнее набрать, чем пытаться попасть мизинцем по нужной скобке.

З.Ы. А тот, кто одним пальчиком по клаве тычет, так какой это программёр... Про таких и говорить даже не буду!

))

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

VD>>Ну тут тебе могут возразить что многим фигурные скобки кажутся очень неудобными, а бегин с этдом очень даже. Это просто дело вкуса. На качестве языка это не сильно сказывается.

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

Z2>Это смотря какой стороны сие явление рассматривать. Я вот слепым методом набираю, так по мне begin\end гораздо удобнее набрать, чем пытаться попасть мизинцем по нужной скобке.

Да уж "немногословность" Си и присущая ему неоднозначность многих конструкций не слишком радуют.

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

AVK>Я писал на Дельфи, причем довольно много. То что он сказал в общем то совершенно верно.

Так ты ещё ко всем прочим твоим недостаткам и на Дельфях писал... Понятно.

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

Z2>Это смотря какой стороны сие явление рассматривать. Я вот слепым методом набираю, так по мне begin\end гораздо удобнее набрать, чем пытаться попасть мизинцем по нужной скобке.

Трененуй мизинец.

Я правда по-английски не вслепую пишу, но по-русски на х и ъ поподаю... обычно

Z2>З.Ы. А тот, кто одним пальчиком по клаве тычет, так какой это программёр... Про таких и говорить даже не буду!

))

С комплит вордом и двумя пальцами код долбится довльно шустро. Правда о тексте этого сказать нельзя. Я вот до сих пор по ангилиски долблю двумя пальцами, а по-русски в слепую.

VD>Трененуй мизинец.

Я правда по-английски не вслепую пишу, но по-русски на х и ъ поподаю... обычно

На х и ъ я тоже попадаю, только нужны они бывают гораздо реже, чем {} в С

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

))

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

VD>>Трененуй мизинец.

Я правда по-английски не вслепую пишу, но по-русски на х и ъ поподаю... обычно

Z2>На х и ъ я тоже попадаю, только нужны они бывают гораздо реже, чем {} в С

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

))

Зато после Си и оттопыривания мизинца будет хорошая распальцовка, что в жизни пригодится

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

AVK>>Я писал на Дельфи, причем довольно много. То что он сказал в общем то совершенно верно.

IT>Так ты ещё ко всем прочим твоим недостаткам и на Дельфях писал... Понятно.

IT>)

Ага. А еще на пхп, немножечко на BC++, TP и BP, Watcom'е, да много еще на чем. И вроде этого и не скрывал.

... << Янус 1.0 alpha 10 (developer build) >>

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

VD>Трененуй мизинец.

Я правда по-английски не вслепую пишу, но по-русски на х и ъ поподаю... обычно

То то я гляжу кто то в исходниках януса слова на букву х пишет

VD>С комплит вордом и двумя пальцами код долбится довльно шустро. Правда о тексте этого сказать нельзя. Я вот до сих пор по ангилиски долблю двумя пальцами, а по-русски в слепую.

После нескольких лет писания еще на BP выработалась привычка — begin[Enter]end; набирается практически одним нажатием.

... << Янус 1.0 alpha 10 (developer build) >>

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

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

DM>>Ну и совсем не правда!

VD>Ну гляди здесь. Все наши программисты от трех до семи лет отработали на паскале. Кода было решено делать компоненты, пересели на VC. Половина С++ знала еще до ОПаскля... кое кто изучал С++ как второй язык. На сегодня такого бреда как здесь от них не услышишь. Только здравые оценки что удобно там, что там.

Блин!!!

Батенька, я же по русски писал вроде, не по китайски (оным не владею), так и читайте что написано, а не что сами придумали. Если вы не знаете, кто такой средне статистический программер на Делфи, то это не моя проблемма. Просвещу сразу, таких здесь мало, и не надо мне на оных ссылаться, а те самые более сродни программерам на VB, так как система тоже RAD. Кстати я не говорил, что эти люди не способны переучиться, я лишь говорю, что для них это намного сложнее, чем просто сменить платформу. (надо разбираться в том что такое винды)
VD>
VD>ЗЫ

VD>После сторого яязка все остальные уже не вызывают таких эмоций... ну еще один синтаксический изыск... ну еще один рантайм. В том же VC есть несклько рантайм подсистем программирование под которых требует совершенно разных знаний. Так создавать десктоп приложение и на MFC совсем не тоже самое, что делать ActiveX-компоненты, ну а писать сервисы не похоже не на первое не не второе.

Ну и к чему это было сказано, в чем суть? Я тоже писал и на паскале и на васике, а уж потом пересел на VC. Дело же совсем не в изысках и не рантайм подсистемах (пальцы просто по стенке скребут), а в уровне требуемом для работы на Дэльфи. Если опять что не понятно — ОБРАЩАЙТЕСЬ!!!

Только не надо придумывать, то чего я не говорил и показывать на крутых программеров с криком: "Вот и все мы такие!!!". В данном вопросе имеют смысл только вероятностные оценки и не в коем случае не абсолютные. Если захочется повторить свою мысль, то выразите ее в процентах статистики (по вашему мнению).

ЗЫ А все таки они пересели на VC.

Здравствуйте Аноним, Вы писали:

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

A>>Здравствуйте Аноним, Вы писали:

А>>>Помимо многого прочего, ты еще и не знаешь, что в виртовом Паскале типа string как раз не было! Там были array [??..??] of char и только-то! И гемороишше был с ними ишшо тот!

A>>Хм. Нет, помоему те здесь не прав. Там строки всегда были.

А>Нет, они появились только в Трупо-Паскале. До того существовала только возможность присвоения строкового литерала массиву из char.

Бред.
В виртовском Паскале были строки: тип String, с максимальным размером 255 символов, где на позиции 0 стояло 8-битное целое, указывающее на длину строки.
Поэтому работа со Паскаль-строками происходит быстрее чем с такой же длины "строками" языка Це — эмуляция, массив символов, цепочка с нуль-терминатором и т.д..

Вообще-то, Це — это язык операционных систем. Прикладные вещи на нём пишутся и выглядят просто ужасно, конечно, если до этого доберуться шаловливые ручки системного программиста...

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

А>>>>Помимо многого прочего, ты еще и не знаешь, что в виртовом Паскале типа string как раз не было! Там были array [??..??] of char и только-то! И гемороишше был с ними ишшо тот!

A>>>Хм. Нет, помоему те здесь не прав. Там строки всегда были.

А>>Нет, они появились только в Трупо-Паскале. До того существовала только возможность присвоения строкового литерала массиву из char.

ZEN>Бред.
ZEN>В виртовском Паскале были строки: тип String, с максимальным размером 255 символов, где на позиции 0 стояло 8-битное целое, указывающее на длину строки.

Не знаешь — не пиши. В виртовском Паскале строк string не было. Прежде чем вопить "бред", открой любой учебник по паскалю 70-80-х годов (а не по Турбо-Паскалю!).

ZEN>Поэтому работа со Паскаль-строками происходит быстрее чем с такой же длины "строками" языка Це — эмуляция, массив символов, цепочка с нуль-терминатором и т.д..

Вот это как раз и есть бред — заявлять что что-то "быстрее" без учета специфики использования.

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

ZEN>... Прикладные вещи на нём пишутся и выглядят просто ужасно, ...

А это, батенька, уже не от языка, а от криворучия зависит

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

Дык, на то он и системный

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

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

VD>Паскль обделен такими сдедствами упрощения работы как шаблоны, макросы и множественное наследование. Но без них можно жить и даже создавать очень эффективные программы. В томже пращуне С++ языке С небыло ни шаблонов, ни множественного наследования, ни даже хоть какого нибудь наследования и тем не менее и сегодня на нем можно писать код скоростные характеристики которого близки к максимуму. В конечном итоге намного больше зависит от рук/головы программиста и от качества проектирования.

Так то оно так, но я имею ввиду отсутствие элементарного удобства.

VD>Возможности определяются двумя вещами: знаниями программиста и начальным базисом. Дельфи дает фору с точки зрения базиса (компоненты, рад среду, ...), но для получения качественного продукта нужен еще и программист с высокой квалификацией.

Жалко что этого до сих пор многие не понимают

DS>>P.P.S. "Язык определяет способ нашего мышления и предопределяет, о чем мы можем думать". Б.В.Ворф

VD>Глупейшее высказывание. Особенно в отношении к языкам программирования.

.

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

DS>>Так вот, Дельфи предопределила думать о Tкомпонентах, событиях, формах и т.п.

VD>Да тебя зазомбировали.

Где в Дельфи написано что нужно всегда искать нужный компонент, а не написать дцать строчке кода? Все дел лишь в том что простота Дельфи и VB сплатила вокруг этих RAD-сред большие армии ламеров. В мире Дельфи и VB есть много высоко-классных специалистов, просто их не видно за толпами бездорей и начинающих.

Вот я и говрил здесь большей частью с точки зрения таких лемеров и бездарей. Дело в том, что им то этого никто не объяснил (что в Дельфи можно еще и код бацать

)

VD>PS

VD>Поодбные ветки ничего кроме флэйма не дают я уже пытался отвечать на подобный впрос Отличие Visual C++ от Builder C++.

Я полностью тут согласен. И как это я опять дал себя втянуть в эти бессмысленные рассуждения

Здравствуйте Ибрагим, Вы писали:

И>Возможго, что тебе Долфи нравится. Но это еще ничего не значит. Дельфист — постоянно сидящий в дельфи и презирающий VC.

Что-то я мало видел дельфистов которые ненавидят VC. Зато встречал множество сишников, которые с пеной у рта доказывали что Дельфи — полный отстой а С++ — рулит. На вопрос а чем он лучше сказать никто не смог, даже программисты из серьезных контор. Кстати такие настроения возникали уже у детишек, которые только начинали изучать С++. Может все дело в том, что приверженцы С++ до сих пор помнят, что первый паскаль создавался для обучения? Не пора ли пересмотреть их отношение к языку.

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

V>Готов поспорить.
V>Есть разница. Причем большая.
V>Был на фирме программер на Delphi.
V>Ушел оставив кучу глючного кода. Прихожу я со своим VC.
V>От паскаля помню только то что на первом курсе в обязаловку входило.
V>Результат. Делит весь его код на хрен и написал свой.

V>Вот в чем и разница. Наследование кода от программиста к программисту

V>А с нуля можно писать на чем хош. Выбор языка определяет поставленая задача.

V>Хотя компиляторы Borland неперевариваю. Что си, что билдер, что делфы.

Если у того программиста руки не из того места росли, то это не значит что Дельфи виноваты.

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

DG>P.S. В MFC-и есть хоть какое-то разделение на View/Document, и в книжках про MFC для начинающих хотя бы пару слов про это написано. В Delphi-ых книжках — про разделение логики и отображение соверленно ничего не написано...

DG>А что читает большинство начинающих и не очень? Правильно — "XXX за YYY дней"...

Совершенно согласен. Книжки про Дельфи — полный отстой (по крайней мере те которые мне попадались). Авторы гонятся за звонкой монетой и им, ИМХО, наплевать на читателей. Поэтому такие книги больше не читаю.

А в принципе, если у человека есть голова и терпение он и на базе этих книг и собственных проб и ошибок может научиться программировать. Да и интернет еще никто не отменял.

И>Дельфист — постоянно сидящий в дельфи и презирающий VC.
^^^^^^^^^^^^^^^
Бред.

AK>Совершенно согласен. Книжки про Дельфи — полный отстой (по крайней мере те которые мне попадались). Авторы гонятся за звонкой монетой и им, ИМХО, наплевать на читателей. Поэтому такие книги больше не читаю.

Только по Delphi с книжками такие проблемы?

По-моему — не только.
Даже по .NET есть — Троелсен — тоже такая водянистая, что просто ужас. Один плюс — пожалуй самая широкоохватная книжка на русском по этой тематике.

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

CL>А вобще работодатели дельфю любят (это мое мнение). Т.к. дельфи программист раз-два и собрал программу. Неважно, что она УЖЕ весит больше мегабайта. Неважно, что постоянно вылезают глюки. Не важно, что для того чтобы работать с базами данных надо устанавливать дельфю на целевой компьютер (сам с этим сталкивался, когда мне предложили поюзать дельфовую прогу юзающую BDE).

Ну для того чтобы поюзать базу на BDE вовсе не надо ставить Delphi целиком — достаточно поставить BDE, или просто скопировать в папку с программой нужные файлы. Да и вообще BDE практически умер уже. При современных технических средствах 1-2 МБ не являются ососбым минусом. Насчет того, что вылезают глюки — может просто программа написана криво. А насчет что там любят работодатели.... Они скорее всего любят результат, ИМХО.

P.S. А насчет раз-два и программа готова — наверное по этому и глюки, и плохой инсталятор, и соответствующее отношение к продукту в целом.

Есть такая вещь как Install Shield Express. Очень удобная штука. Собираешь файлы в кучу, ставишь галки и готово. В 90% случае больше не надо.

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

AVK>Не совсем корректная аналогия. Корректнее было бы так — один готовит в микроволновке, а другой на углях. Наверное большинство здесь предпочтут ту что на углях, но ведь и в микроволновке можно вкусно приготовить, и на углях гадость, в микроволновке можно больше куриц приготовить за единицу времени и приготовление в онной требует меньше квалификации, а кому то на углях желудок не переваривает и т.д. и т.п.

Осталось решить что микроволновка а что угли.

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

AK>Что-то я мало видел дельфистов которые ненавидят VC. Зато встречал множество сишников, которые с пеной у рта доказывали что Дельфи — полный отстой а С++ — рулит.

Ну вот только не надо. Точно так же я могу сказать, что не разу не видел, чтобы очередная Holy War была начата сишниками, вечно этих паскалистов завидки берут

В общем Влад тут уже по-моему устал объяснять что такое демагогия.

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

AK>Осталось решить что микроволновка а что угли.

А это уж каждый выбирает себе сам по вкусу.

... << Янус 1.0 alpha 10 (developer build) >>

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

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

muh>>) Весьма прелюбопытное по архитектуре зрелище должно быть будет

Особенно учитывая то, что ребята из Бормана, похоже, как и МС, без серъезных огрехов работать все-таки не могут

VD>Все элементарно... Будет язык с бегинами вместо фигурных скобок и оперетором := вместо += для назначения событий. Будет поддерживать винформсы и разные асп.нет-ы с веб-сервисами. Из изюминок обещают портацию VCL приложений. Т.е. пишут обертки для VCL-я.

VD>Ну, а что получится... Ну еще один язык для дотнэта с возможностью легкого перехода с Дельфи.

VD>Бета компилятрора шла с бэтой Дельфи 7, так что уже скоро мы увидим Дельфи.Нет.

Вопрос весьма большой. Учитывая то, что им потребовалось четыре года на реализацию новых фич Common Controls 4.71 в VCL, я не испытываю оптимизма относительно времени, потребного для переноса VCL в CLR.
Проблема в том, что Delphi != Object Pascal. Компилятор они сделают уже со дня на день — вона hacker_delphi уже забабахал свои превые формочки под D7.Net developer preview. Но вот VCL... Замахнулись они, конечно, круто. Если им все удастся, то некоторую часть добра с Torry.net можно будет просто перекомпилять с минимальными косметическими изменениями. Но огромные тонны кода в существующих проектах завязаны на 3rd-party компоненты, которые будут переползать под .Net еще несколько лет.

Лично я считаю, что максимально возможная версия Delphi — восьмая.

Дело в том, что тот замечательный RTTI, благодаря которому они порвали всех в нише RAD, просто отдыхает на багамах по сравнению с .Net. И новому поколению компонент-девелоперов просто нахрен не надо будет пользовать язык с неполной синтаксической поддержкой .Net фич в пользу RAD. Они напишут на футболках "Скажи .НЕТ джаве!" и "Теперь RADость доступна всем!"
Да, Delphi будет жить. Но развивать его уже никто не станет по чисто коммерческим причинам.

Иду учить MSIL, CLR, C#...

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

DS>P.S. Имея ввиду "Дельфи" я подразумевал среду Borland C++ Builder, т.к. считаю, что человек, попробовавший С++ на Паскаль никогда не посмотрит (если его, конечно, не будут вынуждать обстоятельства).

Человек, попробовавший C++, никогда не посмотрит на C++ Builder. Это все равно, что поставить стрелу от крана на BMW. Разработчиков — посажат в одиночки и вручить полное собрание Страуструпа вплоть до осознания заблуждений, буде таковое наступит.

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

AK>Что-то я мало видел дельфистов которые ненавидят VC. Зато встречал множество сишников, которые с пеной у рта доказывали что Дельфи — полный отстой а С++ — рулит. На вопрос а чем он лучше сказать никто не смог, даже программисты из серьезных контор. Кстати такие настроения возникали уже у детишек, которые только начинали изучать С++. Может все дело в том, что приверженцы С++ до сих пор помнят, что первый паскаль создавался для обучения? Не пора ли пересмотреть их отношение к языку.

Дык ИМХО пересмотреть енто отношение лоджен его производитель

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

IT>Ну вот только не надо. Точно так же я могу сказать, что не разу не видел, чтобы очередная Holy War была начата сишниками, вечно этих паскалистов завидки берут

Я стараюсь не доводить до вас свои домыслы.К сожалению это из моей личной практики. Я абсолютно лояльно отношусь и к С++, и к VC, и к Delphi, и к Basic и т.д. Силой обстоятельств начал работать на Delphi. Просто раньше немного обижало отношение к себе как к низшему классу, с некоторой надменной снисходительностью со стороны людей, которые изучали С. Это при том, что знаний у них были гораздо меньше. Сейчас, к счастью, научился этого не замечать.

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

DS>Дык ИМХО пересмотреть енто отношение лоджен его производитель

Что он для этого, по вашему, должен изменить в языке?

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

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

AK>
DS>>Дык ИМХО пересмотреть енто отношение лоджен его производитель

AK>Что он для этого, по вашему, должен изменить в языке?

Да пустой это разговор. Не дам себя очередной раз спровоцировать на флейм

Интересно, а сама Delphi на чем написана и какая среда разработки
при этом использовалась? Я знаю, что VC++ написан в VC++.

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

K> Интересно, а сама Delphi на чем написана и какая среда разработки
K>при этом использовалась? Я знаю, что VC++ написан в VC++.

Компилятор кажется на С. Среда разрабоки(Delphi) на языке Object Pascal.

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

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

DAS>
K>> Интересно, а сама Delphi на чем написана и какая среда разработки
K>>при этом использовалась? Я знаю, что VC++ написан в VC++.

DAS> Компилятор кажется на С. Среда разрабоки(Delphi) на языке Object Pascal.

Delphi
Компилятор на C, скомпилирован с помощью BCB.
Среда на Delphi, скомпилирована с помощью Delphi.

C++ Builder
Все компилеры/линкеры на C
Среда на Delphi, скомпилирован с помощью Delphi.

Легко посмотреть с помошью любой тулзы определяющей библиотеки и компилятор/линкер

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

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

DS>>P.S. Имея ввиду "Дельфи" я подразумевал среду Borland C++ Builder, т.к. считаю, что человек, попробовавший С++ на Паскаль никогда не посмотрит (если его, конечно, не будут вынуждать обстоятельства).

S>Человек, попробовавший C++, никогда не посмотрит на C++ Builder. Это все равно, что поставить стрелу от крана на BMW. Разработчиков — посажат в одиночки и вручить полное собрание Страуструпа вплоть до осознания заблуждений, буде таковое наступит.

Хм. У тебя какое-то слишком категоричное мнение.Ты слово 'imho' забыл написать.

Для меня C++ Builder это возможность RADоваться как на Delphi, но при этом не испытывать неудобства от Object Pascal.

На работе я сейчас пишу не на нем, но недавно небольшой проект по вытягиванию сообщений из NNTP и запаковки в chm написал именно под BCB. Против Delphi ничего не имею, но Object Pascal меня в данный момент раздражает. Если пописать только на нем пару недель то наверное вновь привыкну, но желания не было.

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

AK>Совершенно согласен. Книжки про Дельфи — полный отстой (по крайней мере те которые мне попадались).

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

А книги надо выбирать уметь. Посмотри в соответствующем форуме или на сайте пол Delphi

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

AK>Что-то я мало видел дельфистов которые ненавидят VC. Зато встречал множество сишников, которые с пеной у рта доказывали что Дельфи — полный отстой а С++ — рулит. На вопрос а чем он лучше сказать никто не смог, даже программисты из серьезных контор.

Это потому что для того чтобы сказать чем один язык лучше другого надо прилично знать оба. А это невозможно если ты ненавидишь один из них.

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

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

И>>Дельфист — постоянно сидящий в дельфи и презирающий VC.
IT> ^^^^^^^^^^^^^^^
IT>Бред.

Да нет бывает. Правда они его обычно "заочно" презирают, т.к. не разу не видели

Да нет начинать то ее может любой, но Delphi действительно обычно оказывается в конечном итоге обороняющейся стороной.

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

A>Ну дак это недостаток который относится не к Delphi а к тебе. Книжки надо уметь выбирать. Назови мне любую технологию и я для нее тебе найду плохую книжку.

A>А книги надо выбирать уметь. Посмотри в соответствующем форуме или на сайте пол Delphi

Я вроде бы не жаловался на то что не умею выбирать книги. Я говорил про наиболее покупаемые книги, в красивых обложках с классными скриншотами и обещаниями научить всему дней за несколько без отрыва от производства. И то что есть спрос на эти книги, вследствии чего их абсолютное большинство в магазинах, считаю вовсе не своим недостатком.

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

AK>Я вроде бы не жаловался на то что не умею выбирать книги. Я говорил про наиболее покупаемые книги, в красивых обложках с классными скриншотами и обещаниями научить всему дней за несколько без отрыва от производства.

Ты уверен что они самые покупаемые? Их много но тираж у них на самом деле так себе.

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

A>Ты уверен что они самые покупаемые? Их много но тираж у них на самом деле так себе.

Насчет самых покупаемых действительно может быть погорячился.

Здравствуйте Аноним, Вы писали:

А>>>>>Помимо многого прочего, ты еще и не знаешь, что в виртовом Паскале типа string как раз не было! Там были array [??..??] of char и только-то! И гемороишше был с ними ишшо тот!
A>>>>Хм. Нет, помоему те здесь не прав. Там строки всегда были.
А>>>Нет, они появились только в Трупо-Паскале. До того существовала только возможность присвоения строкового литерала массиву из char.
ZEN>>Бред.
ZEN>>В виртовском Паскале были строки: тип String, с максимальным размером 255 символов, где на позиции 0 стояло 8-битное целое, указывающее на длину строки.
А>Не знаешь — не пиши. В виртовском Паскале строк string не было. Прежде чем вопить "бред", открой любой учебник по паскалю 70-80-х годов (а не по Турбо-Паскалю!).

Что ж, достаточно посмотреть ISO-стандарт языка Pascal (стандарт — он и в Америке стандарт, так?).

ZEN>>Поэтому работа со Паскаль-строками происходит быстрее чем с такой же длины "строками" языка Це — эмуляция, массив символов, цепочка с нуль-терминатором и т.д..
А>Вот это как раз и есть бред — заявлять что что-то "быстрее" без учета специфики использования.

Вся специфика в том, что тип строки зарезервирован в языке Pascal как один из других встроенных типов, а это значит, что под это дело заведена ран-тайм-база.
В Це же приходится использовать или библиотеки, которые занимают много, или собственные наработки, не лишённые кривизны.
Кто будет спорить?

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

ZEN>>>В виртовском Паскале были строки: тип String, с максимальным размером 255 символов, где на позиции 0 стояло 8-битное целое, указывающее на длину строки.
А>>Не знаешь — не пиши. В виртовском Паскале строк string не было. Прежде чем вопить "бред", открой любой учебник по паскалю 70-80-х годов (а не по Турбо-Паскалю!).

ZEN>Что ж, достаточно посмотреть ISO-стандарт языка Pascal (стандарт — он и в Америке стандарт, так?).

Стандарт тут, как ни странно, ни при чем. Мы говорим о виртовском Паскале. Стандартизация Паскаля прошла, кажется, в начале 90-х, намного позже. Что туда напихали — даже и смотреть неинтересно, т. к. к реальности этот стандарт не имеет ровным счетом никакого отношения. Как документ, стандарт Паскаля не стоит бумаги, на которой напечатан.

Даже собственно виртовский Паскаль всегда реализовывался с какими-нибудь отклонениями, но реализовывался. А вот о реализациях Паскаля по стандарту я не слыхал.

Теперь о строках. Я на Паскале а-ля Вирт писал. Строк там нет. Нету строк. Строк нет! Ясно?

ZEN>>>Поэтому работа со Паскаль-строками происходит быстрее чем с такой же длины "строками" языка Це — эмуляция, массив символов, цепочка с нуль-терминатором и т.д..
А>>Вот это как раз и есть бред — заявлять что что-то "быстрее" без учета специфики использования.

ZEN>Вся специфика в том, что тип строки зарезервирован в языке Pascal как один из других встроенных типов, а это значит, что под это дело заведена ран-тайм-база.
ZEN>В Це же приходится использовать или библиотеки, которые занимают много, или собственные наработки, не лишённые кривизны.
ZEN>Кто будет спорить?

Я буду спорить. Никакой такой особой поддержки, каковую нельзя обеспечить силами языка Си, строкам (вообще строкам) не нужно. Все просто: на Си можно применять какой угодно подход к работе со строками без ущерба производительности. Вот на Паскале — это не так.

А>Теперь о строках. Я на Паскале а-ля Вирт писал. Строк там нет. Нету строк. Строк нет! Ясно?

Ага, согласен полностью. Господа незнайки, хорош гнать. Строк в виртовском Паскале на самом деле небыло!

А>Я буду спорить. Никакой такой особой поддержки, каковую нельзя обеспечить силами языка Си, строкам (вообще строкам) не нужно. Все просто: на Си можно применять какой угодно подход к работе со строками без ущерба производительности. Вот на Паскале — это не так.

А как? Какой подхоод к работе со строками нельзя применить в Паскале? Ась???

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

А>>Я буду спорить. Никакой такой особой поддержки, каковую нельзя обеспечить силами языка Си, строкам (вообще строкам) не нужно. Все просто: на Си можно применять какой угодно подход к работе со строками без ущерба производительности. Вот на Паскале — это не так.

Z2>А как? Какой подхоод к работе со строками нельзя применить в Паскале? Ась???

Как написать operator+ или operator= ???

DM>Как написать operator+ или operator= ???

s:= "1" + "2";

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

DM>>Как написать operator+ или operator= ???

Z2>s:= "1" + "2";

Z2>)

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

DM>>Как написать operator+ или operator= ???

Z2>s:= "1" + "2";

Z2>)

А что будешь делать если надо работать не со строками, а с матрицами? Наверно тоже напишешь C := A+B;

DM>А что будешь делать если надо работать не со строками, а с матрицами? Наверно тоже напишешь C := A+B;

Разговор вроде шёл о том, что есть какие-то "методы работы со строками", которые в Паскале нельзя реализовать?

Если вы мне хотите доказать что паскаль язык убогий — то не надо. Я и сам это знаю.

)

З.Ы. А матрицы на Фортране надо умножать, а не на С++.

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

DM>>А что будешь делать если надо работать не со строками, а с матрицами? Наверно тоже напишешь C := A+B;

Z2>Разговор вроде шёл о том, что есть какие-то "методы работы со строками", которые в Паскале нельзя реализовать?

Z2>Если вы мне хотите доказать что паскаль язык убогий — то не надо. Я и сам это знаю.

)

Ну ладно здесь я не буду спорить, есть и др. тема.

Z2>З.Ы. А матрицы на Фортране надо умножать, а не на С++.

А вот это очень спорно, по меньшей мере. Чем библиотеки C++ по работе с матрицами хуже фортрановских?

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

K> Интересно, а сама Delphi на чем написана и какая среда разработки
K>при этом использовалась? Я знаю, что VC++ написан в VC++.
Delphi написан на Delphi

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

TL>Да, Паскаль почти ничего не умеет.

Бейсик и тот лучше.

А что не умеет Паскаль и умеет С++?
(Про множественное наследование не надо

)

)) Нет, тут, как мне кажется, явно что-то не так, как хотелось бы...

И мне тоже так кажется.

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

V>Готов поспорить.
V>Есть разница. Причем большая.
V>Был на фирме программер на Delphi.
V>Ушел оставив кучу глючного кода. Прихожу я со своим VC.
V>От паскаля помню только то что на первом курсе в обязаловку входило.

Если бы помнил больше, может и не пришлось бы код стирать

V>Результат. Делит весь его код на хрен и написал свой.

V>Вот в чем и разница. Наследование кода от программиста к программисту

V>А с нуля можно писать на чем хош. Выбор языка определяет поставленая задача.

Хехе, это верно, но мне кажется, что вы уже навсегда для себя выбрали VC для всех задач. Правильно ли это?

Интересно, мне почему-то кажется, что когда вы уйдете из этой конторы и придет новый программер он тоже сотрет весь ваш код. Я почти готов на деньги поспорить.

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

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

Y>>Мое мнение таково — единственной оценкой крутости проффесионального програмиста может быть только количесто денег которое он зарабатывает....

DM>Вот пример совершенно не верного мнения.

Эти вещи не находятся в такой банальной зависимости. Зарплата определяется спросом, а уж потом классом.

Хехе, зарплата В ПРЕВУЮ ОЧЕРЕДЬ определяется классом, а уж потом спросом (минимальный спрос есть всегда, если есть профессия).

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

K>А что не умеет Паскаль и умеет С++?
K>(Про множественное наследование не надо

)

Чего лично мне не хватает дак это stl(Про то что его можно заменить TList-ами и тп не надо

. Ну и библиотек для него поменьше, чтобы на том же WinAPI что-то сложное там поюзать надо кучу header-ов в паскаль поконвертить.

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

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

HD>
K>> Интересно, а сама Delphi на чем написана и какая среда разработки
K>>при этом использовалась? Я знаю, что VC++ написан в VC++.
HD>Delphi написан на Delphi

Только IDE. Компилятор, тулзы, BDE итп на C. Я сам смотрел специально.

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

TL>>Да, Паскаль почти ничего не умеет.

Бейсик и тот лучше.

K>А что не умеет Паскаль и умеет С++?
K>(Про множественное наследование не надо

)

Шаблоны

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

K>Здравствуйте The Lex, Вы писали:

TL>>Да, Паскаль почти ничего не умеет.

Бейсик и тот лучше.

K>А что не умеет Паскаль и умеет С++?
K>(Про множественное наследование не надо

)

Что ж, Паскаль многое умеет из того, что умеет C++. Вопрос еще в том, как он это умеет и как тем, что умеет Паскаль, умеют пользоваться программисты, умеющие пользоваться Паскалем...

Ну и еще вопрос: ну и куда то, что умеет Паскаль из того, что умеет C++, воткнуть в саму идеологию Паскаля?

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

W>P.S. Я, кстати, прекрасно пишу и на C++

Да ты и на русском вроде писать умеешь. Но получается все рвно ************

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

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

DS>[skiped]

[skipped]
Сорри, что ответил не сразу — как-то замотался...
Так вот, я писал про Borland Pascal 6.0/7.0, а не про Delphi.

Например, TurboVision... аналогов на QC я не очень-то видел (ну... была такая ZInc, но она не Мелкософтная

)
Так что извиняйте за невольное направление мыслей не туда.
А ешшо могу сказать, что объявление переменных в отдельных блоках, всякие begin/end, скобки при множественых условиях в if — все это приучает к аккуратности. Так что язык действительно определяет образ мЫшления... (прошу не думать, что я выступаю против Ц++ — нет, я и сам на ниш иногда пишу, как и на Ц#, JScript, VBScript, VBA, VB, ASM и т.д.)
я не говорю против Ц++ — я говорю за Дельфи! нельзя назвать среду разработки плохой потому, что ей пользуются неспециалисты.
Можно провести аналогию с автомобилями TOYOTA. то, что TOYOTA — самый распространенный в нашем отечестве импортный автомобиль и , соответственно на нем чаще, чем на другом импортном автотранспорте ездят чайники еще не значит, что машина плохая... они вон даже в Формулу 1 пошли... и говорят, что для новой команды результаты у них неплохие...
Так и с Дельфи — то, что вы не знаете профессионалов, которые великолепно владеют Delphi и умеют совмещать код Delphi с кодом на других ЯП (иногда — и в одном проекте) не значит, что таковых нет, а Дельфи — отстой... просто Борланд чуть лучше заботится о своих юзверях

Всем спасибо

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

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

Z2>>Это смотря какой стороны сие явление рассматривать. Я вот слепым методом набираю, так по мне begin\end гораздо удобнее набрать, чем пытаться попасть мизинцем по нужной скобке.
угу, особенно когда в Code compleate вводиш вот такой макрос:

macro beginend;
------------
begin
  |
end;

тогда пишешь be Ctrl+J — и думать не надо

VD>Трененуй мизинец.

Я правда по-английски не вслепую пишу, но по-русски на х и ъ поподаю... обычно

Z2>>З.Ы. А тот, кто одним пальчиком по клаве тычет, так какой это программёр... Про таких и говорить даже не буду!

))

VD>С комплит вордом и двумя пальцами код долбится довльно шустро. Правда о тексте этого сказать нельзя. Я вот до сих пор по ангилиски долблю двумя пальцами, а по-русски в слепую.

что, настока страшно по-русски получается, что даже и глаза поднять стыдно, да???

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

но зато доки набирать (чем в последнее время часто страдать приходится) приходится медленно... но ничего вот на РСДНе натренируюсь — тогда и поглядим

... тока вот клавы в последнее время плохие — постоянно не успевают регистр переключить

для них 240 символов в минуту — это слишком много.

так что вот!
ВНИМАНИЕ! Конкурс! кто подскажет клавиатуру, которая по "скоронаборности" лучше, чем Mitsumi — тому счастье будет.

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

HD>... просто Борланд чуть лучше заботится о своих юзверях

Ага, особенно приятно пользоваться почти самой "лучшей" IntelliSense в средах от борланда

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

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

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

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

Y>>>>Там была формулировка — "крутую", я ее понял как "очень хорошую". Написание хорошого GUI — это очень весомы показатель, хороший GUI одинаково трудно создать и в Delphi и в VC.

DM>>>Ну и совсем не правда!

HD>>А я очень хотел бы увидеть исполнение СНОСНОГО, НО ПРАВИЛНО НАПИСАНОГО контрола для Дельфи написаного программером, всю жисть работавшим на Ц++ + МФЦ

DM>Ну ты блин даешь. Что может быть проще написания не сложного контрола на API или ATL. А это все есть и в Дэльфи. Программер перебираясь из VC не по причине своей слабости как программист спокойно напишет такой контрол. А вот сможет, ли Дэльфист все время проработавший на какую-то фирмочку по продаже продуктов питания (а такие программеры и есть самые массовые среди Дэльфистов)использовать этот контрол, в этом я бы усомнился.

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

че сказал — сам не понял... но оно РУ-У-У-У-У-У-УЛИТ, однозначно

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

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

HD>>... просто Борланд чуть лучше заботится о своих юзверях

DS>Ага, особенно приятно пользоваться почти самой "лучшей" IntelliSense в средах от борланда

Ей только в BCB "приятно" пользоваться, в Delphi она и на самом деле неплоха

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

HD>что, настока страшно по-русски получается, что даже и глаза поднять стыдно, да???

Не то слово...

HD>ВНИМАНИЕ! Конкурс! кто подскажет клавиатуру, которая по "скоронаборности" лучше, чем Mitsumi — тому счастье будет.

Значит говоришь не вслепую и 240... клава говоришь мешает...

На собеседовании девушка ищущая место сикритарши...
— С какой скоростью набираете текст?
— 300 знаков в минуту!
— О-ГО!
— Но такая фигня получается...

... << RSDN@Home 1.0 alpha VladD2.1.0.alpha 11.1.0.1019.1018 >>

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

А люди которые пишут клиентов на Дельфях в 90% случаях ламера.

полагаю, это в равной степени относится и к пишущим на иных языках

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

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

S> А люди которые пишут клиентов на Дельфях в 90% случаях ламера.

S>полагаю, это в равной степени относится и к пишущим на иных языках

В общем случае — нет. На некоторых языках ламера не пишут, потому что это слишком сложно. Они просто переходят к более простым. Вроде Дельфи. %)

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

Z2>Это смотря какой стороны сие явление рассматривать. Я вот слепым методом набираю, так по мне begin\end гораздо удобнее набрать, чем пытаться попасть мизинцем по нужной скобке.
Нашел проблему, елки-палки: на кнопку тяжело нажимать.
Ведь все это решается сменой раскладки клавиатуры — назначь ты себе фигурные скобки на кнопки поближе к середине клавы — и никаких проблем.

Z2>З.Ы. А тот, кто одним пальчиком по клаве тычет, так какой это программёр... Про таких и говорить даже не буду!

))

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

Z2>Это смотря какой стороны сие явление рассматривать. Я вот слепым методом набираю, так по мне begin\end гораздо удобнее набрать, чем пытаться попасть мизинцем по нужной скобке.

Z2>З.Ы. А тот, кто одним пальчиком по клаве тычет, так какой это программёр... Про таких и говорить даже не буду!

))

Я уже вроде как то писал — после долгих лет програмленья на паскале скобки begin..end; набирались буквально одним движением руки, клаву только мягкую надо и без клика, на тех что с кликом раздавался жуткий треск.

Ну и еще приличные клавы программленьем на паскале у меня снашивались за полгода.

... << RSDN@Home 1.0 beta 1 (developer build)>>

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

A>... А что такое хорошее MS сделала я вообще не видел.

Т.е. как это не видел?! А сейчас ты все это в чем читаешь?!

Здравствуйте, Аноним, Вы писали:

А>... но не было ни одного восторга в этом топике в пользу С++ как мощного средства объектно-ориентированного программирования...

Да просто все считают это само собой разумеющимся и просто забывают это периодически указывать...

Здравствуйте, Ибрагим, Вы писали:

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

И>>>Профи в чем ? Профи — это лэйба типа офицерского звания.
И>>>Ты профи в игрушках, возможно, если постоянно этим занимаешься.
И>>>Так что все логично.

Y>>Т.е. по вашему человек не может быть профи в нескольких вешах одновременно?

И>Профессионал — человек зарабатывающий определенной профессией на жизнь. Разнорабочий — не профессионал.

И>Если ты умеешь готовить очень хорошо — это не значит, что ты профессиональный повар.
И>Когда ты занимаешься чем то профессионально, зачем тебе еще одна профессия ? Потому что основная не дает заработка ? Абсурд.

И>Профессионал — применяется к определенной предметной области, а не инструменту.
И>Профессионализм подразумевает очень глубокие знания в одной, узкой, области.

И>Профессионал — человек, знающий все ни о чем. Смежный предметные области ты будешь хорошо знать, но не профессионально.

И>Чем отличается профессионал от опытного программиста непрофессионала ? Профессионал обзан решать все проблемы, возникающие на пути. Если проект требует прыжка через голову или предусмотрения 1000 мелочей, то профессионал должен это сделать. Иначе проект не сдаст и кушать будет не на что.

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

Уважаемый Ибрагим! Вы, по-моему, немного путаетесь в русском, а именно в значениях слов "профессионал", "специалист", "эксперт"...

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

TL>Здравствуйте, Anatolix, Вы писали:
A>>... А что такое хорошее MS сделала я вообще не видел.
TL>

Т.е. как это не видел?! А сейчас ты все это в чем читаешь?!

Я, например, всю эту лабуду читаю в Mozilla и нигде больше. Некоторые используют Opera, NN, Phoenix и др.

Ну и что?
Я пока не вижу для себя альтернативы Windows на десктопе. Но главное то, что многие приложения, которые я использую, не носят логотип MS и имеют "корни" в OpenSource.
И это радует.

P.S. У этой компании есть "копии" всех известных программ, но свои и убогие. — мысль из фильма "Антитрест".

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

А>>... но не было ни одного восторга в этом топике в пользу С++ как мощного средства объектно-ориентированного программирования...
TL>Да просто все считают это само собой разумеющимся и просто забывают это периодически указывать...

Где критерии мощности?
Вы считаете, что костыли, которые приделали к Си и назвали всё вместе Си++, являются критерием мощности?

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

ZEN>Здравствуйте, The Lex, Вы писали:

TL>>Здравствуйте, Anatolix, Вы писали:
A>>>... А что такое хорошее MS сделала я вообще не видел.
TL>>

Т.е. как это не видел?! А сейчас ты все это в чем читаешь?!

ZEN>Я, например, всю эту лабуду читаю в Mozilla и нигде больше. Некоторые используют Opera, NN, Phoenix и др.

ZEN>Ну и что?
ZEN>Я пока не вижу для себя альтернативы Windows на десктопе. Но главное то, что многие приложения, которые я использую, не носят логотип MS и имеют "корни" в OpenSource.
ZEN>И это радует.

Хм... Ну, в общем-то о браузере я не подумал, да запамятовал.

Статистику использования различных браузеров в интернет не сложно найти...

Что касается OpenSource — э-э-э... Я лучше промолчу, а то у меня мнение сильно злобное...

ZEN>P.S. У этой компании есть "копии" всех известных программ, но свои и убогие. — мысль из фильма "Антитрест".

Фильма не видел. Мысль не поддерживаю.

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

ZEN>Здравствуйте, The Lex, Вы писали:

А>>>... но не было ни одного восторга в этом топике в пользу С++ как мощного средства объектно-ориентированного программирования...
TL>>Да просто все считают это само собой разумеющимся и просто забывают это периодически указывать...

ZEN>Где критерии мощности?

Кто где?

Какие еще критерии?

Бог есть всемогущ, C++ есть мощное средство ООП — какие там еще могут быть критерии для предопределенных догм?

ZEN>Вы считаете, что костыли, которые приделали к Си и назвали всё вместе Си++, являются критерием мощности?

Ну-ну... Я в основном деньги считаю, как свои, так и чужие. Свои просто так, чужие — за деньги.

Костыли, говорите? А вы Object Pascal видели?

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

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

ZEN>>Здравствуйте, The Lex, Вы писали:

А>>>>... но не было ни одного восторга в этом топике в пользу С++ как мощного средства объектно-ориентированного программирования...
TL>>>Да просто все считают это само собой разумеющимся и просто забывают это периодически указывать...

ZEN>>Где критерии мощности?

TL>Кто где?

Какие еще критерии?

Бог есть всемогущ, C++ есть мощное средство ООП — какие там еще могут быть критерии для предопределенных догм?

ZEN>>Вы считаете, что костыли, которые приделали к Си и назвали всё вместе Си++, являются критерием мощности?

TL>Ну-ну... Я в основном деньги считаю, как свои, так и чужие. Свои просто так, чужие — за деньги.

Костыли, говорите? А вы Object Pascal видели?

Прошу прощения за некоторое сравнение, никого не хочу обидеть. Мне данная ветка очень напоминает сюжет из фильма "Каникулы Петрова и Васечкина".

Процитирую немножко:

— Я первая заметила
— Я первая увидела
— Ну что ты, Оля, не кричи..
— Ты, Оля просто вредина!
— САМА ТЫ ОЛЯ ВРЕДИНА!
....

Не надоело?

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

AK>Здравствуйте, The Lex, Вы писали:

TL>>...что-то маы там писали...

AK>Прошу прощения за некоторое сравнение, никого не хочу обидеть. Мне данная ветка очень напоминает сюжет из фильма "Каникулы Петрова и Васечкина".

AK>Процитирую немножко:

AK>- Я первая заметила
AK>- Я первая увидела
AK>- Ну что ты, Оля, не кричи..
AK>- Ты, Оля просто вредина!
AK>- САМА ТЫ ОЛЯ ВРЕДИНА!
AK>....

AK>Не надоело?

Надоело!

Хочу каникулы!!!

Еще 27 дней до Нового Года!!!

Здравствуйте, AndrewK, Вы писали:
AK>
AK>Прошу прощения за некоторое сравнение, никого не хочу обидеть. Мне данная ветка очень напоминает сюжет из фильма "Каникулы Петрова и Васечкина".

AK>Процитирую немножко:

AK>- Я первая заметила
AK>- Я первая увидела
AK>- Ну что ты, Оля, не кричи..
AK>- Ты, Оля просто вредина!
AK>- САМА ТЫ ОЛЯ ВРЕДИНА!
AK>....

AK>
AK>Не надоело?

Жутко похоже ! )))
И вообще о чем спор ! Я лично не понимаю ))
Каждый волен выбирать средство разработки и никто не смеет его называть "ламером" или еще как то, только потому что он пишет на том или на сем! Причем что интересно — те кто этим занимается зачастую никогда и не видело, то, что хают )) Мое мнение таково, что настоящий профессионал владеет в совершенстве исскуством программирования и несколькими средами разработки, а использует ту — которая больше всего отвечает требованиям поставленной задачи! Из начала обсуждения я понял что те кто знает WinAPI — супер-крутые перцы )), а что они будут делать когда их попросят написать что то под Unix-подобное !? )))

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

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

DG>
DG>Можно развить и аналогию с языками...
DG>Допустим во французском языке нет слова "курица" или слова "микроволновка", тогда не понятно как сможет французский повар прочитать рецепт про приготовление курицы в это самой микроволновке.

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

DG>Но это уже будут не то.

Ой, простите меня, но не могу удержаться!

Ага, как же: не то это будет! Как раз самое то!!!

Ты немецкий язык видел?

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

S>Часто приходится слышать мнение, что разработчики, использующие delphi -
S>ваще не программисты, а так... детишки неразумные.

Polniy marazm. Horoshiy programmer — eto tot kotoriy umeet proanalizirovat' problemu, postavit' zadachu i ee reshit'. Tut reshaushuyu rol' igratet opit i stil' mishleniya. Plohoi programmer — tot, kto prochitav Stroustroup'a i imeya opit raboti v 1 god nachinaet vipendrivat'sya, tipa "C++ eto cool, a vse ostal'noe — hernya".

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

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

DG>Вдогонку...

S>>>По-вашему, чем вызвано такое негативное отношение?

DG>Если приходит человек и говорит, что написал GUI-программу на VC на WinApi (или даже на MFC), это значит что этот человек набрался хоть каких-то знаний о Windows,
DG>а если приходит человек и говорит, я тут сбацал крутую GUI-программу на Delphi, то это говорит только о том, что человек умеет держать мышку...

Собственно, в том и беда российского программиста — он считает, что лучше написать слабенькую программку и набраться знаний, нежели написать хорошую просто держа мышку. Что ж делать, если Delphi специально предназначен для написания крутых GUI-программ?
Другое дело, что ничего кроме GUI на Delphi лучше не писать. Но для этого и существует mixed language programming.

WC>Собственно, в том и беда российского программиста — он считает, что лучше написать слабенькую программку и набраться знаний, нежели написать хорошую просто держа мышку. Что ж делать, если Delphi специально предназначен для написания крутых GUI-программ?
WC>Другое дело, что ничего кроме GUI на Delphi лучше не писать. Но для этого и существует mixed language programming.

Ты все болдом пишешь из принципа?

... << RSDN@Home 1.0 beta 2 (developer build)>>

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

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

WC>Что ж делать, если Delphi специально предназначен для написания крутых GUI-программ?

Примеры в студию! Назовите 5 крутых GUI программ написанных на Delphi?

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

Z2>Примеры в студию! Назовите 5 крутых GUI программ написанных на Delphi?

Интересно, а что недоверие какое-то? Или ты считаешь, что на Delphi это невозможно?
Или ты считаешь, что Гуй проще писать на MFC или голом API? Или ты будешь отрицать, что Borland первые написали действительно удобную библиотеку для Windows(OpenWindows)? Или ты вообще сейчас начнешь утверждать, что в Delphi нет доступа к API?

RSDN@Home 1.0 beta 2 РУЛИТ!!!\nСоседей достает, в данный момент: Ария — Смутное время \nОдна голова — хорошо, а две — некрасиво!

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

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

Z2>>Примеры в студию! Назовите 5 крутых GUI программ написанных на Delphi?

HD>Интересно, а что недоверие какое-то? Или ты считаешь, что на Delphi это невозможно?
HD>Или ты считаешь, что Гуй проще писать на MFC или голом API? Или ты будешь отрицать, что Borland первые написали действительно удобную библиотеку для Windows(OpenWindows)? Или ты вообще сейчас начнешь утверждать, что в Delphi нет доступа к API?

Речь не принципиальной возможности, и не о простоте написания графических приложений, а о статистике. Я пять лет программировал на Delphi и соответственно активно интересовался этой темой. Но пять приложений с хорошим GUI написанным на Delphi я назвать не смогу...

Простота эта Delphiйская весьма обманчива. Предлагаю простой эксперимент: попробуй сляпай красивое приложение с парой диалоговых окон средней насыщенности. Запусти. Насладись. А потом переключи размер шрифтов в настройках Windows со small fonts на large fonts. Запусти свою аппликуху и задумайся об обманчивости первого впечатления и о бренности всего сущего.

Или ещё вариант — попробуй сделай в Delphi настраивающийся плавающий toobar. И заставь его работать так как нужно, а не так как позволяют глюки компонентов...

Таким образом получается следующее: чтобы получить действительно хорошее приложение с любым инструментом ты поимеешь достаточно геморроя. Далее: чисто графических приложений не бывает. Всё равно у него должна быть "расчётная часть". А писать и отлаживать её на Delphi — весьма неудобно.

Про доступ к WinAPI — он конечно есть, но... Разумеется Майкрософт тут на 2 шага впереди. Если ты активно пользуешься WinAPI из Delphi — регулярно наталкиваешься на куски неохваченные Windows.pas etc.

З.Ы. Ни один из известных мне хороших и очень хороших программистов пользующих Delphi не делает на нём GUI приложения. В основном это почему-то базы данных с GUI средней паршивости.

З.З.Ы. Кто такое Open Windows? Ты не OWL имеешь в виду? Так оно расшифровывалось Object Windows Library. Моды на "открытость" тогда ещё небыло.

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

Z2>Примеры в студию! Назовите 5 крутых GUI программ написанных на Delphi?

У меня вобще то совсем мало софта, но три я тебе назову

Среда Дельфи
Аргус
The Bat

... << RSDN@Home 1.0 beta 2 (developer build)>>

AVK>Среда Дельфи

Образец интерфейса ПЛОХО подходящего для выполнения своей ОСНОВНОЙ задачи. Конкретно — куча перекрывающихся налезающих друг на друга окошек. Редактор кода перекрывает форму, форма — object inspector и т.д. и т.п.
Горячие клавиши не настраиваются, тулбары висят в одном месте и перемещению не поддаются, докинг в зачаточном состоянии и работает настолько отвратительно, что чаще плюёшь на него чем пользуешься...
Неумелая студенческая поделка в сравнении с Visual Studio.
Если её кто-то рассматривает как образец, то тогда понятно почему так много ублюдочных интерфейсов на Delphi написано.

AVK>Аргус

Что это?

AVK>The Bat

Святого трогать не будем. Луч света в тёмном царстве.

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

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

Z2>Образец интерфейса ПЛОХО подходящего для выполнения своей ОСНОВНОЙ задачи.

Меня устраивал более чем

Z2> Конкретно — куча перекрывающихся налезающих друг на друга окошек. Редактор кода перекрывает форму, форма — object inspector и т.д. и т.п.

Монитор побольше просто надо купить. А для налазящих окошек там докинг есть.

Z2>Горячие клавиши не настраиваются, тулбары висят в одном месте и перемещению не поддаются,

Ты о какой Дельфи речь ведешь? О 2 что ли?

AVK>>Аргус

Z2>Что это?

Фидошный мейлер

Z2>Я же не спорю, не спорю. Растут подчас великолепные цветы и на помойке. Но где же, где тот вал замечательных, красивых, удобных приложений, которые, казалось бы, так просто создать пользуясь Delphi?

А их, красивых и удобных, вобще почти нету, ни на чем.

... << RSDN@Home 1.0 beta 2 (developer build)>>

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

Z2>Речь не принципиальной возможности, и не о простоте написания графических приложений, а о статистике. Я пять лет программировал на Delphi и соответственно активно интересовался этой темой. Но пять приложений с хорошим GUI написанным на Delphi я назвать не смогу...

на какой версии???

Z2>Простота эта Delphiйская весьма обманчива. Предлагаю простой эксперимент: попробуй сляпай красивое приложение с парой диалоговых окон средней насыщенности. Запусти. Насладись. А потом переключи размер шрифтов в настройках Windows со small fonts на large fonts. Запусти свою аппликуху и задумайся об обманчивости первого впечатления и о бренности всего сущего.

Еще один эксперимент: запусти Office 97 с крупными шрифтами... или 2K, без сервиспаков.. у меня — стабильно перекрывающиеся кнопки

Z2>Или ещё вариант — попробуй сделай в Delphi настраивающийся плавающий toobar. И заставь его работать так как нужно, а не так как позволяют глюки компонентов...

Есть компоненты, есть...искать надо уметь. щаз точно не назову, но у меня было несколько пакетов с исходниками, которые все это делали.
Кстати, мне плывучие тулбары не особо и нужны... переставить с места на место — да ,иногда, а плавать — неудобно...

Z2>Таким образом получается следующее: чтобы получить действительно хорошее приложение с любым инструментом ты поимеешь достаточно геморроя. Далее: чисто графических приложений не бывает. Всё равно у него должна быть "расчётная часть". А писать и отлаживать её на Delphi — весьма неудобно.

А какие претензии к "расчетной части"???

Z2>Про доступ к WinAPI — он конечно есть, но... Разумеется Майкрософт тут на 2 шага впереди. Если ты активно пользуешься WinAPI из Delphi — регулярно наталкиваешься на куски неохваченные Windows.pas etc.

Все необходимое — есть, а недостающие части... за 20 минут пишется конвертер хидеров/полуавтомат — и все

Z2>З.Ы. Ни один из известных мне хороших и очень хороших программистов пользующих Delphi не делает на нём GUI приложения. В основном это почему-то базы данных с GUI средней паршивости.

Ню-Ню... вопрос тогда в хорошести и/или наличии соответствующих задач... я вот под Delphi БД почти не пишу, хотя программирую на Delphi уже 9 лет.

Z2>З.З.Ы. Кто такое Open Windows? Ты не OWL имеешь в виду? Так оно расшифровывалось Object Windows Library. Моды на "открытость" тогда ещё небыло.

Сорри... обшибочка вышла...

RSDN@Home 1.0 beta 2 РУЛИТ!!!\nСоседей достает, в данный момент: Ария — Вот и все дела! \nВек живи — век учись!

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

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

Z2>>Образец интерфейса ПЛОХО подходящего для выполнения своей ОСНОВНОЙ задачи.

AVK>Меня устраивал более чем

А с чем ты сравнивал?

Z2>> Конкретно — куча перекрывающихся налезающих друг на друга окошек. Редактор кода перекрывает форму, форма — object inspector и т.д. и т.п.

AVK>Монитор побольше просто надо купить.

Монитор — 21" у меня был, когда я в Delphi работал. Ещё больше нужен?

AVK>А для налазящих окошек там докинг есть.

Ага, Object Inspector стыкуешь к Code Editorу, очень полезная вещь! ;( Вот если бы Object Inspector стыковался к редактируемой форме, так ведь — фигушки!

Z2>>Горячие клавиши не настраиваются, тулбары висят в одном месте и перемещению не поддаются,

AVK>Ты о какой Дельфи речь ведешь? О 2 что ли?

Горячие клавиши не настраиваются вплоть до 6й версии. Тулбары — я имел в виду docking, а не floating.

AVK>>>Аргус

Z2>>Что это?

AVK>Фидошный мейлер

Во дела, оказывается ФИДО до GUI доросло...

Отрадно слышать!

Z2>>Я же не спорю, не спорю. Растут подчас великолепные цветы и на помойке. Но где же, где тот вал замечательных, красивых, удобных приложений, которые, казалось бы, так просто создать пользуясь Delphi?

AVK>А их, красивых и удобных, вобще почти нету, ни на чем.

Аминь.

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

Z2>А с чем ты сравнивал?

VS.NET
JBuilder
IDEA
JCreator
Together ControlCenter
Forte for Java

AVK>>Монитор побольше просто надо купить.

Z2>Монитор — 21" у меня был, когда я в Delphi работал. Ещё больше нужен?

И чего куда у тебя там налазит тогда?

Z2>Ага, Object Inspector стыкуешь к Code Editorу, очень полезная вещь! ;( Вот если бы Object Inspector стыковался к редактируемой форме, так ведь — фигушки!

Да, придумал, ничего не скажешь. Вон даже в обдоканой насквозь VS.NET до такого не додумались.

Z2>Во дела, оказывается ФИДО до GUI доросло...

Отрадно слышать!

Ему уж лет 5 наверное, 2 года его уже не обновляют.

... << RSDN@Home 1.0 beta 2 (developer build)>>

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

HD>на какой версии???
1-5, с шестой уже не успел, только чуть-чуть поковырялся.

HD>Еще один эксперимент: запусти Office 97 с крупными шрифтами... или 2K, без сервиспаков.. у меня — стабильно перекрывающиеся кнопки

97 я срыл в 99м году, и больше на этот ужас смотреть не хочу.

Я не зато что где-то проще\лучше это сделано чем в Дельфи, я за то, что в дельфи ТОЖЕ куча гемора, если хочешь нормальный интерфейс иметь.

HD>Есть компоненты, есть...искать надо уметь. щаз точно не назову, но у меня было несколько пакетов с исходниками, которые все это делали.

А5 куча гемора и дополнительных денег. Приличные наборы компонентов покупать приходится... Нормальные кряки фиг найдёшь.

HD>Кстати, мне плывучие тулбары не особо и нужны... переставить с места на место — да ,иногда, а плавать — неудобно...

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

HD>А какие претензии к "расчетной части"???

Шаблонов и макросов нетъ. Отладчик — посредственный. (Правда и им никто не умеет пользоваться

.

Z2>>Про доступ к WinAPI — он конечно есть, но... Разумеется Майкрософт тут на 2 шага впереди. Если ты активно пользуешься WinAPI из Delphi — регулярно наталкиваешься на куски неохваченные Windows.pas etc.

HD>Все необходимое — есть, а недостающие части... за 20 минут пишется конвертер хидеров/полуавтомат — и все

А потом 20 дней отлавливаются глюки... Если бы всё было так просто — борланд бы сама всё переконвертила мигом.

HD>Ню-Ню... вопрос тогда в хорошести и/или наличии соответствующих задач... я вот под Delphi БД почти не пишу, хотя программирую на Delphi уже 9 лет.

ого! А релиз первой версии-то был в конце 1994... В разработке чтоли участие принимал???

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

HD>Еще один эксперимент: запусти Office 97 с крупными шрифтами... или 2K, без сервиспаков.. у меня — стабильно перекрывающиеся кнопки

У меня крупные шрифты последние несколько лет везде стоят — пока ничего особенного в продуктах Microsoft не замечал. MS Office 97?

Прекрасный аргумент!!! А Borland Delphi в 97-м году каким был?

Вообще-то, интерфейс Delphi как среды разработки общепризнан как прекрасной идеей

, так и корявой реализацией

. ИМХО, разумеется.

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

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

AVK>>>Монитор побольше просто надо купить.

Z2>>Монитор — 21" у меня был, когда я в Delphi работал. Ещё больше нужен?

AVK>И чего куда у тебя там налазит тогда?

То одно, то другое... окошко с кодом захочешь распахнуть — оно всё на свете сразу и перекроет, к примеру.

Z2>>Ага, Object Inspector стыкуешь к Code Editorу, очень полезная вещь! ;( Вот если бы Object Inspector стыковался к редактируемой форме, так ведь — фигушки!

AVK>Да, придумал, ничего не скажешь. Вон даже в обдоканой насквозь VS.NET до такого не додумались.

Ну, там почти, почти идеал уже...

К оснвному окну прекрасно докируется... Вот если бы ещё не ко всему окну, а именно к той его вкладке где форма... чтоб когда форму открыл — пропертя перед глазами, на код ушёл — с глаз их долой.

))

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

Z2>ого! А релиз первой версии-то был в конце 1994... В разработке чтоли участие принимал???

Блин.. вечно я годы первого курса Колледжа и 1 курса Универа путаю... канечно в 95... сорри, опять обшибся...

RSDN@Home 1.0 beta 2 РУЛИТ!!! Соседей достает, в данный момент: Ария — Свет дневной иссяк... "Век живи — век учись!"

Так, ребята, давайте не будем тыкать пальцами в бесплатное говно и говорить, что оно невкусно.
Вообще Борланд скорее всего намеренно поставляла убогую реализацию VCL, чтобы поддержать сторонних разработчиков.
Сама возможность сооружать такие вещи, как QuantumGrid, является огромным достижением. Микрософт вот только-только доползает до такого с .NET.
А то блин купят диск за 45 рублев и давай его поливать...

Пользуюсь RSDN@Home 1.0 beta 2 (custom tuned), слушая 12. Crying days (remixed)

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

S>Так, ребята, давайте не будем тыкать пальцами в бесплатное говно и говорить, что оно невкусно.
S>Вообще Борланд скорее всего намеренно поставляла убогую реализацию VCL, чтобы поддержать сторонних разработчиков.
S>Сама возможность сооружать такие вещи, как QuantumGrid, является огромным достижением. Микрософт вот только-только доползает до такого с .NET.
S>А то блин купят диск за 45 рублев и давай его поливать...

Ну, братец... Между прочим Delphi Enterprise Edition стоит $2400. А ты его говном, да ещё бесплатным...

... << RSDN@Home 1.0 beta 2 >>[br]Boss cried: "Oh, where is the program we must have?!"[br]And fired one programmer, and then there were FF.

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

А ты его купил??? Или на рынке взял за 40-100 р???

RSDN@Home 1.0 beta 2 РУЛИТ!!! Соседей достает, в данный момент: Ария — Пробил час "Одна голова — хорошо, а две — некрасиво!"

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

S>Так, ребята, давайте не будем тыкать пальцами в бесплатное говно и говорить, что оно невкусно.
S>...

Полностью поддерживаю товарища Синклера

(хотя и не покупал дисков за 45р)

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

HD>А ты его купил??? Или на рынке взял за 40-100 р???

А что, если б купил за $2400, оно б волшебным образом лучше сделалось?

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

Z2>Ну, братец... Между прочим Delphi Enterprise Edition стоит $2400. А ты его говном, да ещё бесплатным...

http://msdn.microsoft.com/vstudio/howtobuy/pricing.asp

на самом деле тоже не слабая — цена

П.С. — только давайте не раздувать данный флейм дальше и сравнивать цена качество

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

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

HD>А ты его купил??? Или на рынке взял за 40-100 р???

Купил. За 160 рублей.

А что если бы я его купил, потребительские качества резко улучшились бы? Вон я Лингво 7.0 как-то купил. Глючит так же, как и раньше глючил.

З.Ы. И кончай на меня наезжать. Я не решал и в ближайшее время не буду решать, покупать конторе софт официально или пиратский использовать.

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

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

HD>>А ты его купил??? Или на рынке взял за 40-100 р???

S>А что, если б купил за $2400, оно б волшебным образом лучше сделалось?

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

RSDN@Home 1.0 beta 2 РУЛИТ!!! Соседей достает, в данный момент: Ария — Беспечный ангел (караоке) "1 Км <> 1024 м."

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

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

Z2>>Ну, братец... Между прочим Delphi Enterprise Edition стоит $2400. А ты его говном, да ещё бесплатным...

TAT>http://msdn.microsoft.com/vstudio/howtobuy/pricing.asp

TAT>на самом деле тоже не слабая — цена

TAT>П.С. — только давайте не раздувать данный флейм дальше и сравнивать цена качество

Я не про цены говорил, а про то, что Дельфи далеко не бесплатная, как нам Синклер тут ляпнул.
А если ты хочешь про M$ услышать — так VS Enterprise Architect всё-таки поболее фич включает чем Delphi Enterprise Edition.

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

S>>А что, если б купил за $2400, оно б волшебным образом лучше сделалось?

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

А причем здесь саппорт, если Sinclair говорил про "бесплатное говно", имея в виду "убогую реализацию VCL"?

Z2>Ну, братец... Между прочим Delphi Enterprise Edition стоит $2400. А ты его говном, да ещё бесплатным...

Нда. Погорячился.

Пользуюсь RSDN@Home 1.0 beta 2 (custom tuned), слушая 12. Crying days (remixed)

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

AVK>А их, красивых и удобных, вобще почти нету, ни на чем.
А Янус ты на чем пишешь? Уже довольно удобно и красиво хотя и пока не доделано.

... << RSDN@Home 1.0 beta 2 Тихо>>

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

AVK>>А их, красивых и удобных, вобще почти нету, ни на чем.
WH>А Янус ты на чем пишешь? Уже довольно удобно и красиво хотя и пока не доделано.

Ну так я и на Дельфи не хуже писал.

... << RSDN@Home 1.0 beta 2 (np: тихо) >>

Toolbars...
Z2>А5 куча гемора и дополнительных денег. Приличные наборы компонентов покупать приходится... Нормальные кряки фиг найдёшь.

Toolbar2000 www.jrsoftware.com $20

Или free с исходниками, если совесть не замучает.
Супер компоненты, глюков уже очень дано нет, поддержка превосходная.

Увы — реальных прог действительно маловато.... Впрочем, огромное кол-во софта российских предприятий... наверное среди них есть неплохие вещи

AVK>Среда Дельфи
AVK>Аргус
AVK>The Bat

WebZip
QuickDesk/IBExpert — последний уже довольно сильно наворочен...

Здравствуйте, zaiats_2k, Вы писали:
S>> А люди которые пишут клиентов на Дельфях в 90% случаях ламера.

S>>полагаю, это в равной степени относится и к пишущим на иных языках

Z2>В общем случае — нет. На некоторых языках ламера не пишут, потому что это слишком сложно. Они просто переходят к более простым. Вроде Дельфи. %)

Возможно, но мне таких языков не известно. Ламеры пишут, к примеру, и на assembler и на PL/SQL of Oracle.

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

S>Возможно, но мне таких языков не известно. Ламеры пишут, к примеру, и на assembler и на PL/SQL of Oracle.
Во во. Ламер это состояние дущи.

RSDN@Home 1.0 beta 3 silent

... << RSDN@Home 1.0 beta 3 >>

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

Y>Извиняйте за небольшой офтопик, что Вы, уважаемые гуру межете сказать плохого
Y>про C#, если уже сравнивать его с Delphi и C.

У, гадская вещь. Это как наркотик, один раз подсел, и все. Вот сегодня делал отчет в 1С — была жуткая ломка.

... << RSDN@Home 1.0 beta 3 (np: тихо) >>

Y>Извиняйте за небольшой офтопик, что Вы, уважаемые гуру межете сказать плохого
Y>про C#, если уже сравнивать его с Delphi и C.

Гуру — не гуру, но скажу

Мне например, немножко не нравится взятая из java схема, когда тело метода нельзя оторвать от его декларации... В паскале есть interface/implementation и это красиво. В C/C++ есть хедеры — тоже разнесены интерфейс и реализация...

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

IT>Гуру — не гуру, но скажу

IT>Мне например, немножко не нравится взятая из java схема, когда тело метода нельзя оторвать от его декларации... В паскале есть interface/implementation и это красиво. В C/C++ есть хедеры — тоже разнесены интерфейс и реализация...

Да уж, зашибись красота. Особенно красиво свойства на Дельфи описывать. Пару раз весь текст туда сюда промотаешь. В общем ничего кроме лишней работы отделение интерфейса не дает.

... << RSDN@Home 1.0 beta 3 (np: тихо) >>

AVK>Да уж, зашибись красота. Особенно красиво свойства на Дельфи описывать. Пару раз весь текст туда сюда промотаешь. В общем ничего кроме лишней работы отделение интерфейса не дает.

Вот еще один премер того, что идеального языка быть не может — одному нравится так, другому — эдак...

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

AVK>Здравствуйте, Igor Trofimov, Вы писали:

AVK>Да уж, зашибись красота. Особенно красиво свойства на Дельфи описывать. Пару раз весь текст туда сюда промотаешь. В общем ничего кроме лишней работы отделение интерфейса не дает.
Угу... тока с Delphi 4 появились замечательные кнопки Ctrl+Up, Ctrl+Down, Ctrl+Shift+C... и многое другое... надо Хелпы читать изредка

silent

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

AVK>>Да уж, зашибись красота. Особенно красиво свойства на Дельфи описывать. Пару раз весь текст туда сюда промотаешь. В общем ничего кроме лишней работы отделение интерфейса не дает.
HD>Угу... тока с Delphi 4 появились замечательные кнопки Ctrl+Up, Ctrl+Down, Ctrl+Shift+C... и многое другое... надо Хелпы читать изредка

Да знаю я про эти кнопочки, без них вобще жить трудно, но не всегда они спасают.

... << RSDN@Home 1.0 beta 3 (np: тихо) >>

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

AVK>Здравствуйте, Igor Trofimov, Вы писали:

IT>>Гуру — не гуру, но скажу

IT>>Мне например, немножко не нравится взятая из java схема, когда тело метода нельзя оторвать от его декларации... В паскале есть interface/implementation и это красиво. В C/C++ есть хедеры — тоже разнесены интерфейс и реализация...

AVK>Да уж, зашибись красота. Особенно красиво свойства на Дельфи описывать. Пару раз весь текст туда сюда промотаешь. В общем ничего кроме лишней работы отделение интерфейса не дает.

Можно еще CodeExplorer попользоваться. Или закладками. Это всего навсего организация работы. Один раз выработал схему и работай по ней. Потом не замечаешь как она начинает поддерживаеться моторными навыками. Просто надо не плеваться если что-то не получается, а немного подумать.
Кстати об отдельно описанных интерфейсах — это можно рассматривать еще как содержание у книги. Посмотрел, понял, что-то стало более интересно, то заглянул глубже. Не так ли?

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

AK>Можно еще CodeExplorer попользоваться. Или закладками. Это всего навсего организация работы. Один раз выработал схему и работай по ней.

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

AK>Потом не замечаешь как она начинает поддерживаеться моторными навыками. Просто надо не плеваться если что-то не получается, а немного подумать.

Не стоит мне рассказывать как в Дельфи работать, я с ней за 5 лет в свое время наковырялся по самое нехочу.

AK>Кстати об отдельно описанных интерфейсах — это можно рассматривать еще как содержание у книги. Посмотрел, понял, что-то стало более интересно, то заглянул глубже. Не так ли?

Не так. Вот как раз для того чтобы просмотреть чистый интерфейс есть всякие класс-эксплореры

... << RSDN@Home 1.0 beta 3 (developer build)>>

AVK>Это геморой, ради которого приходится выпендриваться и изобретать всякие шоткеи, эксплореры и прочую мишуру.

Точно также геморрой — что-то понять в большом C#/Java без эксплореров, outline проч. Все перемешано... Так что либо мы оцениваем язык на бумаге — либо в совокупности с средствами, облегчающими работу на компе.

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

IT>Точно также геморрой — что-то понять в большом C#/Java без эксплореров, outline проч.

А там умные люди делают один класс — один файл. Так что обычно никаких проблем. А в дальнейшем можно будет держать один класс в нескольких файлах.

IT>Все перемешано... Так что либо мы оцениваем язык на бумаге — либо в совокупности с средствами, облегчающими работу на компе.

Некогда мне сейчас этим флеймом заниматься.

... << RSDN@Home 1.0 beta 3 (np: тихо) >>

Ага, люди из RitLABS — ламеры? Ага!

)))

В курсе, что The Bat! написана на дельфях?

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

КАА>Ага, люди из RitLABS — ламеры? Ага!

)))

КАА>В курсе, что The Bat! написана на дельфях?

Кстати, пост DarkGrey'я не противоречит твоему...

... << RSDN@Home 1.0 beta 3 >>

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

КАА>Ага, люди из RitLABS — ламеры? Ага!

)))

КАА>В курсе, что The Bat! написана на дельфях?
Де-жа-вю-у-у! Это уже было.
Ну прибейте кто-нибудь эту ветку, и товарища этого. Если уж запостил в ветку, так прочитай перед этим ее. Действительно, пустопорожние разговоры!

... << RSDN@Home 1.0 beta 3 >>

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

КАА>Ага, люди из RitLABS — ламеры? Ага!

)))

КАА>В курсе, что The Bat! написана на дельфях?

Информация к размышлению:
Dos Navigator у них был написан на Borland Pascal-e + Turbo Vision.

Свой выбор на Delphi они скорее всего остановили исходя из того, что Паскаль они уже знали.

Так что знай они C++ может быть у них Bat еще лучше бы получился

pps
Смотрел я на код Dos Navigator-а и я бы не сказал, что он хорошо написан (в плане структурированности).
Не на пустом месте они же не стали его переписывать под Windows...

Здравствуйте, zaiats_2k, Вы писали:
WC>>Что ж делать, если Delphi специально предназначен для написания крутых GUI-программ?

Z2>Примеры в студию! Назовите 5 крутых GUI программ написанных на Delphi?
Посмотри Магнат-софт! Система автоматизации производства:
1 — работает на 500 рабочих мест.
2 — 13 немецких заводов работают именно под ней.
Имеет внутренний макро язык. ну и т.д.
Dmitriy

Я2>>Примеры в студию! Назовите 5 крутых GUI программ написанных на Delphi?
А>Посмотри Магнат-софт! Система автоматизации производства:
А>1 — работает на 500 рабочих мест.
А>2 — 13 немецких заводов работают именно под ней.
А>Имеет внутренний макро язык. ну и т.д.
А>Dmitriy

На лотках нашего города не встречал

Кто официальный дистрибьютор в России, не подскажете?

З.Ы. Тут админ знакомый рассказывал, какая у них крутая система автоматизации производства. Программа на Дельфи — размером 10 мег — один екзешник, ни единой дллки!.. Обновления выходят пару раз в неделю и немедленно доставляются всем юзерам (уж не помню я скока их там сотен). Вот это я понимаю, КРУТО!

))

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

Z2>З.Ы. Тут админ знакомый рассказывал, какая у них крутая система автоматизации производства. Программа на Дельфи — размером 10 мег — один екзешник, ни единой дллки!.. Обновления выходят пару раз в неделю и немедленно доставляются всем юзерам (уж не помню я скока их там сотен). Вот это я понимаю, КРУТО!

))

Он случайно не на почте работает?
А то у нас в конторе для россияйской почты разрабатывают и внедряют кучу софта, причем пишут как под DOS, так и под Windows, и один проект написан на Delphi/Builder C++. Таки там тоже нет DLL. ОДин экзешник. Весит около 6-7 мегов. хотя два года назад весил всего около 2-х мегов.

... << RSDN@Home 1.0 beta 3 >>

K>Он случайно не на почте работает?

Нет, в весьма крутой конторе занимающейся недвижимостью.

Не хочешь, не читай. Никто не тянет.

Где конструктивизм? ДХ

DG>Информация к размышлению:
DG>Dos Navigator у них был написан на Borland Pascal-e + Turbo Vision.
знаю

DG>Свой выбор на Delphi они скорее всего остановили исходя из того, что Паскаль они уже знали.
скорее всего

DG>Так что знай они C++ может быть у них Bat еще лучше бы получился

Лучше и не нужно! Он и так очень хороший

DG>pps
DG>Смотрел я на код Dos Navigator-а и я бы не сказал, что он хорошо написан (в плане структурированности).
И что? Не въехать в него с пол-тычка, это точно

. Мне код тоже не нравится. И что? От этого прога плохая стала? DN в своем роде уникум. Все плагины под фар щас повторяют DN фичи. Такого кайфогово менеджера я не видел и не увижу

.
Ты говорил, что на дельфях не сбацать нормальной проги? Говорил. Говорил, что они ламеры? Говорил. Говорил, что это только БД-ориентированная среда? Говорил. Теперь не отмазывайсся

DG>Не на пустом месте они же не стали его переписывать под Windows...
кого его? The Bat! ?

))))))))
А у тебя неплохо с юмором!

.
Я бы не догодалсся что они DN в Bat перебацали :D))))))))))))))))))))))))))))))

Философия программирования не есть флейм! KAA, не надо провоцировать людей на бессмысленные священные войны своими заявлениями. Будь конструктивнее, пожалуйста. Если по существу сказать нечего — то лучше оставить вопрос без ответа.
Договорились?

Читаю сообщения (особенно про то кто какими пальцами печатает) и вспоминаю как кто-то сказал "программисты работают руками". По-моему все забыли про цель форума (философия ...).

Мне лично cpp нравится больше pascal'я (но это дело вкуса, работал я и на том и на другом).
Нравится мне также, что в C++Builder (можно с оговоркой поставить Delphi) по сравнению с VC можно дозировать усилия: надо интерфейсик с простой функциональностью — элементарно, нужна работа с API (а также и с MFC, кстати) — пожалуйста, это будет похоже на VC. Только особые требования убедят в необходимости писать только на VC.
Нравится мне и reusability сорцов, которая имхо у Delphi достигла непревзойденых высот.

Так что моя философия — экономить свои усилия (и, надеюсь, нервы)

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

DG>>pps
DG>>Смотрел я на код Dos Navigator-а и я бы не сказал, что он хорошо написан (в плане структурированности).

КАА>И что? Не въехать в него с пол-тычка, это точно

. Мне код тоже не нравится.
KAA> И что? От этого прога плохая стала?

Смотря с какой стороны смотреть.
Если смотреть со стороны пользователя, то программа была удачна, если смотреть со стороны программиста, то нет.
Перевести Дос Навигатора под Windows пыталось как минимум две команды (не считая Reatlabs-ов), но у них ничего не вышло путного, потому что постоянно вылазили старые ляпы и ограничения.

КАА>Ты говорил, что на дельфях не сбацать нормальной проги? Говорил. Говорил, что они ламеры? Говорил. Говорил, что это только БД-ориентированная среда? Говорил. Теперь не отмазывайсся

Перечитай внимательно еще раз мои посты, я не говорил, что на Дельфи нельзя написать хорошую shareware, я только говорил, что Delphi не заточена на написание shareware.

Я верю, что мастер, может и микроскопом гвоздь забить, и блоху кувалдой подковать...

DG>>Не на пустом месте они же не стали его переписывать под Windows...
КАА>кого его? The Bat! ?

))))))))

Dos Navigator

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

DG>Перевести Дос Навигатора под Windows пыталось как минимум две команды (не считая Reatlabs-ов), но у них ничего не вышло путного, потому что постоянно вылазили старые ляпы и ограничения.

А разве DN.OSP загнулся? DataCompBoy оттуда ушел по денежным причинам, и проект этого не перенес?

... << Manu Chao — Me Gustas Tu >> ...

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

SB>Так что моя философия — экономить свои усилия (и, надеюсь, нервы)

Надо работать, и работать на том, что знаешь и чем умеешь, а главное — нравится, пользоваться.

Если я правильно мыслю, то это изречение имеет уже автора и всем бы давно пора это понять и не плодить разговоры "Шнень_1 vs Шнень_2 (кто писясьтее?)".

За работу товарищи-господа. Напишем и перепишем Америку по ОСям и IDE-ям.

... << RSDN@Home 1.0 beta 3 >>

Здравствуйте, m.a.g., Вы писали:

MAG>А разве DN.OSP загнулся? DataCompBoy оттуда ушел по денежным причинам, и проект этого не перенес?

Последний раз я интересовался DN-ом, где-то через полгода-год после выкладывания DN в open source. Когда я писал про DN, я основался на этих старых впечатлениях.

ps
Может сейчас, конечно, что-то изменилось. Но судя потому, что DN довольно давно уже ни в каких обзорах и публикациях не мелькает, то DN.OSP так и остался на уровне любительской поделки, интересной только нескольким фанатам.

pps
А что DN до сих пор пытаются развивать? Получается что-то интересное?

Основное направление — Dos? Windows?

Интерфейс — Console?

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

DG>pps
DG>А что DN до сих пор пытаются развивать? Получается что-то интересное?
DG>Основное направление — Dos? Windows?
DG>Интерфейс — Console?

Может, новая тема в Прочем?

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

_>На лотках нашего города не встречал

Кто официальный дистрибьютор в России, не подскажете?
Разработчик — www.magnat.ru

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

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

AVK>>Здравствуйте, Igor Trofimov, Вы писали:

AVK>>Да уж, зашибись красота. Особенно красиво свойства на Дельфи описывать. Пару раз весь текст туда сюда промотаешь. В общем ничего кроме лишней работы отделение интерфейса не дает.
H_D>Угу... тока с Delphi 4 появились замечательные кнопки Ctrl+Up, Ctrl+Down, Ctrl+Shift+C... и многое другое... надо Хелпы читать изредка

А в VS.NET все методы класса отображаются в отдельном окне и какая тогда разница отдельно ли описаны методы от класса — всё равно всё перед глазами.

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

AVK>>>Да уж, зашибись красота. Особенно красиво свойства на Дельфи описывать. Пару раз весь текст туда сюда промотаешь. В общем ничего кроме лишней работы отделение интерфейса не дает.

H_D>>Угу... тока с Delphi 4 появились замечательные кнопки Ctrl+Up, Ctrl+Down, Ctrl+Shift+C... и многое другое... надо Хелпы читать изредка

Code completion он и в африке... А навигационные комбинации — это да, помогает. Как и Ctrl+Click на любое слово.

V>А в VS.NET все методы класса отображаются в отдельном окне и какая тогда разница отдельно ли описаны методы от класса — всё равно всё перед глазами.

А меня сначала угнетала особенность Студии скрывать показывать реализацию (ветки с [+] и [-] слева). Ух как задра....ла.

Но привык, и уже нравится.

А зачем в Дельфи interface и implementation тоже понятно — поддержка быстродействия и однопроходности компилятора.

... << RSDN@Home 1.1 beta 2 >>

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

A>А зачем в Дельфи interface и implementation тоже понятно — поддержка быстродействия и однопроходности компилятора.
Как интересно! А я-то думал, что Вирт это придумал для поддержки модульного программирования. Каким боком одно- или многопроходность компилятора влияет на поддержку инкапсуляции?

... << RSDN@Home 1.1 beta 2 >>

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

A>>А зачем в Дельфи interface и implementation тоже понятно — поддержка быстродействия и однопроходности компилятора.
S>Как интересно! А я-то думал, что Вирт это придумал для поддержки модульного программирования. Каким боком одно- или многопроходность компилятора влияет на поддержку инкапсуляции?

Вирт придумал всего лишь Паскаль, а там нет interface и implementation.

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

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

DG>Вдогонку...

S>>>По-вашему, чем вызвано такое негативное отношение?

DG>Если приходит человек и говорит, что написал GUI-программу на VC на WinApi (или даже на MFC),

Это значит, что человек зря потратил время на изучение такой кучи API функций лишь для того, чтобы написать GUI.

DG>а если приходит человек и говорит, я тут сбацал крутую GUI-программу на Delphi, то это говорит только о том, что человек умеет держать мышку...
Кстати, MFC еще более убогая вещь, там все через wizrd's(читай ж..у) делается.

И вообще — написание GUI не требует и не должно требовать "высокой" квалификации.

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

DG>Зато после Си и оттопыривания мизинца будет хорошая распальцовка, что в жизни пригодится

По Сишникам это заметно

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

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

K>>А что не умеет Паскаль и умеет С++?
K>>(Про множественное наследование не надо

)

A>Чего лично мне не хватает дак это stl(Про то что его можно заменить TList-ами и тп не надо

. Ну и библиотек для него поменьше, чтобы на том же WinAPI что-то сложное там поюзать надо кучу header-ов в паскаль поконвертить.

Поэтому стоит использовать Delphi, для которых добрые люди из Borland написали нужные dcu

Здравствуйте, <Аноним>, Вы писали:
А>Вирт придумал всего лишь Паскаль, а там нет interface и implementation.
Виноват. прогнал. Думал, что сие есть since the very beginning.

... << RSDN@Home 1.1 beta 2 >>

DOO>И вообще — написание GUI не требует и не должно требовать "высокой" квалификации.

Ага, а результат этой лёгкости можно наблюдать на любом сборнике mp3 "Домашняя Коллекция". Право же, видя подобные "интерфейсы", поневоле соглашаешься с тем, что некоторые вещи должны быть настолько сложными, чтобы ламеры за них не брались никогда...

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

S>Виноват. прогнал. Думал, что сие есть since the very beginning.

Т.е. не надо отвечать?

... << RSDN@Home 1.1 beta 2 >>

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

_>Ага, а результат этой лёгкости можно наблюдать на любом сборнике mp3 "Домашняя Коллекция". Право же, видя подобные "интерфейсы", поневоле соглашаешься с тем, что некоторые вещи должны быть настолько сложными, чтобы ламеры за них не брались никогда...

Ну это как в примере с ножом: можно безобидно хлеб/мясо резать, а можно скальп снять или даже убить.

Или: пошли дурака за водкой, так он одну и принесёт...

... << RSDN@Home 1.1 beta 2 >>

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

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

_>Это смотря какой стороны сие явление рассматривать. Я вот слепым методом набираю, так по мне begin\end гораздо удобнее набрать, чем пытаться попасть мизинцем по нужной скобке.

Не быть тебе пианистом.

... << Posted by RSDN@Home 1.1 beta 2 >>

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

VD>С комплит вордом и двумя пальцами код долбится довльно шустро. Правда о тексте этого сказать нельзя. Я вот до сих пор по ангилиски долблю двумя пальцами, а по-русски в слепую.

А я никак в слепую не надрючусь. Давное ещё привык долбать двумя пальцами на раз-два. Помню, когда приучал себя, всё мысленно считал: "Раз-два, раз-два...", постоянно ускоряя темп. И смотреть на клаву, а не на монитор. Редко голову поднимаю, разве что когда перечитать набранное. Получается таки приемлимо по скорости.

... << RSDN@Home 1.1 beta 2 >>

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

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

VD>>С комплит вордом и двумя пальцами код долбится довльно шустро. Правда о тексте этого сказать нельзя. Я вот до сих пор по ангилиски долблю двумя пальцами, а по-русски в слепую.

A>А я никак в слепую не надрючусь. Давное ещё привык долбать двумя пальцами на раз-два. Помню, когда приучал себя, всё мысленно считал: "Раз-два, раз-два...", постоянно ускоряя темп. И смотреть на клаву, а не на монитор. Редко голову поднимаю, разве что когда перечитать набранное. Получается таки приемлимо по скорости.

Не помню, кто сказал, что надо запретить печатать рассказы на машинках. Чтобы писатели трижды подумали, прежде чем написать слово...

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

K>Здравствуйте The Lex, Вы писали:

TL>>Да, Паскаль почти ничего не умеет.

Бейсик и тот лучше.

K>А что не умеет Паскаль и умеет С++?
K>(Про множественное наследование не надо

)

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

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

DG>>>а если приходит человек и говорит, я тут сбацал крутую GUI-программу на Delphi, то это говорит только о том, что человек умеет держать мышку...

A>>Радикально неверное мнение!

iT>Не, он все правильно сказал — перечитай еще раз. Из слов, что человек написал прогу на Delphi — НЕ СЛЕДУЕТ ПОЧТИ НИЧЕГО. Он может быть супер-программером, который просто больше любит Delphi, но чтобы выяснить это — придется приложить усилия...

Это же относится и к Builder-у. Так что тут язык ни при чем.

Здравствуйте, <Аноним>, Вы писали:

А>...Но только больно уж громозко. То, что в C пишется одним оператором, на Паскале пишется двумя-тремя. А если этот оператор находится в условии, то приходится еще дописывать begin-end. В общем, программа на Паскале раза в полтора длинней такой же программы на C.

Ну просто убийственный аргументище.

Длиннющий энто язык. Так мы ещё договоримся, что C/C++ — это уникальный метод стенографирования. Знать всем серетаршам.

А> Я когда-то переводил программу с C на Паскаль, весь исплевался.

Мне приходилось делать и прямые, и обратные преобразования. Правда, больше с C на OP, и чаще это выглядело как "понять суть, алгоритм действий и написать его (или подобрать) на другом языке". Плеваться, кстати, не помогает. Но несколько таких переводов весьма развивает мозги. И беглое чтение что одного, что другого синтаксиса....

... << RSDN@Home 1.1 beta 2 >>

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

A>Здравствуйте, <Аноним>, Вы писали:

А>>...Но только больно уж громозко. То, что в C пишется одним оператором, на Паскале пишется двумя-тремя. А если этот оператор находится в условии, то приходится еще дописывать begin-end. В общем, программа на Паскале раза в полтора длинней такой же программы на C.

A>Ну просто убийственный аргументище.

По-вашему проще изучить десятипальцевый слепой метод печати?

A>Длиннющий энто язык. Так мы ещё договоримся, что C/C++ — это уникальный метод стенографирования. Знать всем серетаршам.

Обязательно!!!

А>> Я когда-то переводил программу с C на Паскаль, весь исплевался.

A>Мне приходилось делать и прямые, и обратные преобразования. Правда, больше с C на OP, и чаще это выглядело как "понять суть, алгоритм действий и написать его (или подобрать) на другом языке".

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

A>Плеваться, кстати, не помогает.

Конечно не помогает. Переводить надо, а не плеваться.

A>Но несколько таких переводов весьма развивает мозги. И беглое чтение что одного, что другого синтаксиса....

Для этого лучше взять разные языки. Попробуйте взять программу на Паскале и перевести ее на Пролог...

Здравствуйте, Аноним, Вы писали:

А>>>...Но только больно уж громозко. То, что в C пишется одним оператором, на Паскале пишется двумя-тремя. А если этот оператор находится в условии, то приходится еще дописывать begin-end. В общем, программа на Паскале раза в полтора длинней такой же программы на C.

A>>Ну просто убийственный аргументище.

А>По-вашему проще изучить десятипальцевый слепой метод печати?
В Delphi никто уже давно begin-end, а также прочие конструкции языка и имена переменных, типов и т.д. вручную не набирает.

A>>Длиннющий энто язык. Так мы ещё договоримся, что C/C++ — это уникальный метод стенографирования. Знать всем серетаршам.

А>Обязательно!!!
Да нет, C++ — это нормально. Но вот тексты на Perl — это что-то!

А>>> Я когда-то переводил программу с C на Паскаль, весь исплевался.

A>>Мне приходилось делать и прямые, и обратные преобразования. Правда, больше с C на OP, и чаще это выглядело как "понять суть, алгоритм действий и написать его (или подобрать) на другом языке".

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

A>>Плеваться, кстати, не помогает.

А>Конечно не помогает. Переводить надо, а не плеваться.

A>>Но несколько таких переводов весьма развивает мозги. И беглое чтение что одного, что другого синтаксиса....
Затруднения может вызвать перевод как в одну сторону так и вдругую. Попробуй к примеру перевести следующее:

  A := ProbeM;
  SD := [];
  for j := 4 downto 1 do begin
    D := A mod 10;
    A := A div 10;
    if (D in SD) then begin
      Err := -2;
      Break;
    end
    else begin
      Include(SD,D);
      RD[j] := D;
    end;
  end;

Сомневаюсь, что на С++ будет короче.

Здравствуйте, FWP, Вы писали:
FWP>Затруднения может вызвать перевод как в одну сторону так и вдругую. Попробуй к примеру перевести следующее:

  A := ProbeM;
  SD := [];
  for j := 4 downto 1 do begin
    D := A mod 10;
    A := A div 10;
    if (D in SD) then begin
      Err := -2;
      Break;
    end
    else begin
      Include(SD,D);
      RD[j] := D;
    end;
  end;

FWP>Сомневаюсь, что на С++ будет короче.

   A = ProbeM();
     SD = 0;
     for(int j=4; j>0; j--)
     {
            D = A % 10;
            A /= 10;
            if (SD & (1<<D))
            {
                Err = -2;
                break;
            } 
            else 
                SD |= (1<<(RD[j] = D));
     }

... << RSDN@Home 1.1 beta 2 >>

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

S>Здравствуйте, FWP, Вы писали:
FWP>>Затруднения может вызвать перевод как в одну сторону так и вдругую. Попробуй к примеру перевести следующее:
S>

S>  A := ProbeM;
S>  SD := [];
S>  for j := 4 downto 1 do begin
S>    D := A mod 10;
S>    A := A div 10;
S>    if (D in SD) then begin
S>      Err := -2;
S>      Break;
S>    end
S>    else begin
S>      Include(SD,D);
S>      RD[j] := D;
S>    end;
S>  end;
S>

FWP>>Сомневаюсь, что на С++ будет короче.
S>

S>   A = ProbeM();
S>     SD = 0;
S>     for(int j=4; j>0; j--)
S>     {
S>            D = A % 10;
S>            A /= 10;
S>            if (SD & (1<<D))
S>            {
S>                Err = -2;
S>                break;
S>            } 
S>            else 
S>                SD |= (1<<(RD[j] = D));
S>     }
S>

Да, получилось не короче, но бегло воспринять смысл кода стало гораздо сложнее, ИМХО. Хотя — дело привычки...

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

AK>Да, получилось не короче, но бегло воспринять смысл кода стало гораздо сложнее, ИМХО. Хотя — дело привычки...
Именно. Единственная не вполне очевидная вещь — смысл манипуляций с битами. Но следует отметить, что я привел код на голом С++ — без классов. Хорошая библиотека сделает код не менее понятным, чем на Delphi. Что-то типа
{
A = ProbeM();
BitSet<int, 10> SD;
for(int j=4; j>0; j--)
{
D = A % 10;
A /= 10;
if (D < SD)
{
Err = -2;
break;
}
else
SD <<= D;
}
}

... << RSDN@Home 1.1 beta 2 >>

S>  A := ProbeM;
S>  SD := [];
S>  for j := 4 downto 1 do begin
S>    D := A mod 10;
S>    A := A div 10;
S>    if (D in SD) then begin
S>      Err := -2;
S>      Break;
S>    end
S>    else begin
S>      Include(SD,D);
S>      RD[j] := D;
S>    end;
S>  end;
S>

FWP>>Сомневаюсь, что на С++ будет короче.
S>

S>   A = ProbeM();
S>     SD = 0;
S>     for(int j=4; j>0; j--)
S>     {
S>            D = A % 10;
S>            A /= 10;
S>            if (SD & (1<<D))
S>            {
S>                Err = -2;
S>                break;
S>            } 
S>            else 
S>                SD |= (1<<(RD[j] = D));
S>     }
S>

Сдается мне, что в этом коде ошибка. Смысл приведенного фрагмента на Pascal в следующем:
-разобрать 4-х значное целое число;
-если в числе есть повторяющиеся цифры, то сформировать ошибку.
Так вот код на С++ не отловит повторяющиеся нули. Хотя я могу и ошибаться, а под рукой нет С++ компилера.

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

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

AK>>Да, получилось не короче, но бегло воспринять смысл кода стало гораздо сложнее, ИМХО. Хотя — дело привычки...
S>Именно. Единственная не вполне очевидная вещь — смысл манипуляций с битами. Но следует отметить, что я привел код на голом С++ — без классов.
А Pascal код тоже впрочем на чистом Pascal. Еще на Виртовском! 1968 года производства

S>Хорошая библиотека сделает код не менее понятным, чем на Delphi. Что-то типа
S>{
S> A = ProbeM();
S> BitSet<int, 10> SD;
S> for(int j=4; j>0; j--)
S> {
S> D = A % 10;
S> A /= 10;
S> if (D < SD)
S> {
S> Err = -2;
S> break;
S> }
S> else
S> SD <<= D;
S> }
S>}
Приведенный код еще хуже по читаемости чем голый С++

Одно

if (D < SD)

чего стоит

Здравствуйте, FWP, Вы писали:
FWP>Сдается мне, что в этом коде ошибка. Смысл приведенного фрагмента на Pascal в следующем:
FWP>-разобрать 4-х значное целое число;
FWP>-если в числе есть повторяющиеся цифры, то сформировать ошибку.
Ну да
FWP>Так вот код на С++ не отловит повторяющиеся нули. Хотя я могу и ошибаться, а под рукой нет С++ компилера.

С чего бы это? Или кто-то думает, что (1<<0) == 0?

... << RSDN@Home 1.1 beta 2 >>

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

S>

S>                SD |= (1<<(RD[j] = D));
S>

Чем манипулячествовать над битами, не проще ль использовать bitset?

Здравствуйте, FWP, Вы писали:
FWP>А Pascal код тоже впрочем на чистом Pascal. Еще на Виртовском! 1968 года производства

Разве? А по-моему, процедура Include появилась только в Delpi, и то не сразу.
Про читаемость — точно, я не прав. Надо использовать <=, т.к. нас вполне устроит совпадение.
Если хочется большей строгости, то достаточно превратить это в

(BitSet<int, 4>(D) <= SD)

но я предполагаю, что соответствующий неявный конструктор уже объявлен.
Такая запись гораздо ближе к математическому синтаксису "а принадлежит B" (помните "э наоборот?"), чем in.
На плюсах человек вообще довольно быстро отвыкает механически трактовать a++ как inc eax. А для тех, кто не хочет — всегда есть шанс воспользоваться классическим

(SD.Contains(D))

... << RSDN@Home 1.1 beta 2 >>

A>>>Но несколько таких переводов весьма развивает мозги. И беглое чтение что одного, что другого синтаксиса....
FWP>Затруднения может вызвать перевод как в одну сторону так и вдругую. Попробуй к примеру перевести следующее:

FWP>

FWP>  A := ProbeM;
FWP>  SD := [];
FWP>  for j := 4 downto 1 do begin
FWP>    D := A mod 10;
FWP>    A := A div 10;
FWP>    if (D in SD) then begin
FWP>      Err := -2;
FWP>      Break;
FWP>    end
FWP>    else begin
FWP>      Include(SD,D);
FWP>      RD[j] := D;
FWP>    end;
FWP>  end;
FWP>

FWP>Сомневаюсь, что на С++ будет короче.

На C его уже перевели до меня. Теперь текст на Прологе:

test (X, 0, _) :- !.
test (X, N, List) :-
  X1 = X mod 10,
  not member (X1, List),
  X2 = X div 10,
  N1 = N - 1,
  test (X2, N1, [X1| List]).

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

FWP>>А Pascal код тоже впрочем на чистом Pascal. Еще на Виртовском! 1968 года производства

S>Разве? А по-моему, процедура Include появилась только в Delphi

Include появилась толи в 6м толи в 7м Turbo Pascal'е.

Hello, !
You wrote on Wed, 01 Oct 2003 08:58:08 GMT:

> На C его уже перевели до меня. Теперь текст на Прологе:
>

 > test (X, 0, _) :- !.
 > test (X, N, List) :-
 >   X1 = X mod 10,
 >   not member (X1, List),
 >   X2 = X div 10,
 >   N1 = N - 1,
 >   test (X2, N1, [X1| List]).
 >

А где здесь N или N1 на 0 проверяется?

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

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

S>Hello, !
S>You wrote on Wed, 01 Oct 2003 08:58:08 GMT:

>> На C его уже перевели до меня. Теперь текст на Прологе:
>>

 >> test (X, 0, _) :- !.
 >> test (X, N, List) :-
 >>   X1 = X mod 10,
 >>   not member (X1, List),
 >>   X2 = X div 10,
 >>   N1 = N - 1,
 >>   test (X2, N1, [X1| List]).
 >>

S>А где здесь N или N1 на 0 проверяется?

S>Best regards,
S> Sergey.

test (X, 0, _) :- !.

Здравствуйте, zaiats_2k, Вы писали:
_>Include появилась толи в 6м толи в 7м Turbo Pascal'е.
Может быть. Но у Вирта ее совершенно точно не было — было только объединение/пересечение множеств.

... << RSDN@Home 1.1 beta 2 >>

Hello, !
You wrote on Wed, 01 Oct 2003 10:20:38 GMT:

S>> А где здесь N или N1 на 0 проверяется?

> test (X, 0, _) :- !.

Понятно. А где 4 в качестве начального значения N задается?

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

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

S>Здравствуйте, zaiats_2k, Вы писали:
_>>Include появилась толи в 6м толи в 7м Turbo Pascal'е.
S>Может быть. Но у Вирта ее совершенно точно не было — было только объединение/пересечение множеств.

Это настолько важно? Include\Exclude были добавлены в TurboPascal только с одной целью — повышение скорости добавления\удаления одиночного значения в\из множество. Вопреки синтаксису похожему на вызов процедуры, Include и Exclude, это не есть процедуры. Компилируются они в ОДНУ ассемблерную команду. Логически же это тоже самое пересечение множества с другим множеством, состоящим из одного элемента.

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

S>Hello, !
S>You wrote on Wed, 01 Oct 2003 10:20:38 GMT:

S>>> А где здесь N или N1 на 0 проверяется?

>> test (X, 0, _) :- !.

S>Понятно. А где 4 в качестве начального значения N задается?

А это когда даешь команду вроде test (1234, 4, []). Если хочется, можно создать еще одну функцию, вроде

start (X) :- test (X, 4, []).

А можно задать и другое значение. Единственное ограничение — третий параметр должен быть [].

Hello, !
You wrote on Wed, 01 Oct 2003 11:31:38 GMT:

S>> Понятно. А где 4 в качестве начального значения N задается?

> А это когда даешь команду вроде test (1234, 4, []). Если хочется, можно
> создать еще одну функцию, вроде

> start (X) :- test (X, 4, []).

Ну я так и подумал.

> А можно задать и другое значение.

Низзя — это уже другая программа получается, т.е. перевод с паскаля на пролог некорректен.

И, кстати, списков тоже два должно быть, Err не выставляется — как полноценный перевод-то будет выглядеть?

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

Здравствуйте, zaiats_2k, Вы писали:
_>Это настолько важно? Include\Exclude были добавлены в TurboPascal только с одной целью — повышение скорости добавления\удаления одиночного значения в\из множество. Вопреки синтаксису похожему на вызов процедуры, Include и Exclude, это не есть процедуры. Компилируются они в ОДНУ ассемблерную команду. Логически же это тоже самое пересечение множества с другим множеством, состоящим из одного элемента.
Ну так мы и говорим не об ассемблерных командах, а об синтаксисе языка. Дело в том, что в Pascal искусственно введены такие вот синтаксические нелепости, которые призваны обойти отсутствие возможности декларировать

template<class T>
inline Include(bitset<T> &set, T element)
{
  ...
}

которая еще и превращалась бы в одну asm команду. На плюсах сэмулировать этот синтаксис не составляет ни малейшего труда. И даже ввести более удобный.

... << RSDN@Home 1.1 beta 2 >>

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

S>Ну так мы и говорим не об ассемблерных командах, а об синтаксисе языка. Дело в том, что в Pascal искусственно введены такие вот синтаксические нелепости...

Дело в том, что множества были в ведены в Паскаль по причине полного отсутствия там битовых операторов. Я имею в виду Виртовский Паскаль. С тех пор ни там и остались в виде никому не нужного рудимента. На Turbo Pascal ваш пример легко переписать не используюя множесва вообще. И всё это здорово скомпилируется во вполне эффективный код.

Здравствуйте, zaiats_2k, Вы писали:
_>Дело в том, что множества были в ведены в Паскаль по причине полного отсутствия там битовых операторов. Я имею в виду Виртовский Паскаль. С тех пор ни там и остались в виде никому не нужного рудимента. На Turbo Pascal ваш пример легко переписать не используюя множесва вообще. И всё это здорово скомпилируется во вполне эффективный код.
Ок, давайте же сделаем это. Я готов не ограничитваться Torbo Pascal — все, что съест Delphi 7 меня устроит. Что предлагается нам взамен набивших оскомину множеств на Паскале? Кусок кода вроде бы не столь уж велик...

... << RSDN@Home 1.1 beta 2 >>

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

S>Hello, !
S>You wrote on Wed, 01 Oct 2003 11:31:38 GMT:

S>>> Понятно. А где 4 в качестве начального значения N задается?

>> А это когда даешь команду вроде test (1234, 4, []). Если хочется, можно
>> создать еще одну функцию, вроде

>> start (X) :- test (X, 4, []).

S>Ну я так и подумал.

>> А можно задать и другое значение.

S>Низзя — это уже другая программа получается, т.е. перевод с паскаля на пролог некорректен.

S>И, кстати, списков тоже два должно быть, Err не выставляется — как полноценный перевод-то будет выглядеть?

Ну так добавьте еще функцию start:

start (X) :- test (X, 4, []), !.
start (_) :- assert (err (2)), fail.

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

S>Ок, давайте же сделаем это. Я готов не ограничитваться Torbo Pascal — все, что съест Delphi 7 меня устроит. Что предлагается нам взамен набивших оскомину множеств на Паскале? Кусок кода вроде бы не столь уж велик...

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

var
  j, SD, A, D: integer;
begin
  SD := 0;
  for j := 4 downto 1 do begin
    D := A mod 10;
    A := A div 10;
    if ((boolean)((1 shl D) and SD)) then begin
      Err := -2;
      Break;
    end
    else begin
    SD = SD or (1 shl D));
    end;
  end;
end;

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

S>Здравствуйте, zaiats_2k, Вы писали:
_>>Include появилась толи в 6м толи в 7м Turbo Pascal'е.
S>Может быть. Но у Вирта ее совершенно точно не было — было только объединение/пересечение множеств.
Сейчас под рукой нет книги Н.Вирта и К.Йенсен с описанием классического Pascal. Но вот в компиляторе от Йенсен Include() и Declude() уже были. Да и как им не быть, если на типе д.б. определены элементарные операции. Кстати, чем объединение отличается от Include()?

Здравствуйте, zaiats_2k, Вы писали:
Ну, это уже на самом деле перевод перевода. То есть теперь мы имеем длинный текст (одно только выражение ((1 shl D) and SD)<>0 чего стоит), который не является типобезопасным и чреват ошибками. Нам удалось добиться соединения недостатков языков С и Pascal. На мой взгляд, это не то, к чему надо стремиться.

... << RSDN@Home 1.1 beta 2 >>

Здравствуйте, FWP, Вы писали:
FWP>Сейчас под рукой нет книги Н.Вирта и К.Йенсен с описанием классического Pascal. Но вот в компиляторе от Йенсен Include() и Declude() уже были. Да и как им не быть, если на типе д.б. определены элементарные операции. Кстати, чем объединение отличается от Include()?
а) оно работает над множествами, а не над элементами
б) оно не модифицирует аргумент, т.е. a=b+с не совсем то же самое, что a+=b.

... << RSDN@Home 1.1 beta 2 >>

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

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

S>>Ну так мы и говорим не об ассемблерных командах, а об синтаксисе языка. Дело в том, что в Pascal искусственно введены такие вот синтаксические нелепости...

_>Дело в том, что множества были в ведены в Паскаль по причине полного отсутствия там битовых операторов. Я имею в виду Виртовский Паскаль. С тех пор ни там и остались в виде никому не нужного рудимента. На Turbo Pascal ваш пример легко переписать не используюя множесва вообще. И всё это здорово скомпилируется во вполне эффективный код.
И мы получим сишный аналог. И такой же читаемый

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

S>Здравствуйте, zaiats_2k, Вы писали:
S>Ну, это уже на самом деле перевод перевода. То есть теперь мы имеем длинный текст (одно только выражение ((1 shl D) and SD)<>0 чего стоит), который не является типобезопасным и чреват ошибками. Нам удалось добиться соединения недостатков языков С и Pascal. На мой взгляд, это не то, к чему надо стремиться.

В моём тексте какжется было не совсем так, как вы цитируете: "((1 shl D) and SD)<>0)"...
И покажите мне, плиз, "типоопасность" в моём коде?

Да и предназначен он был всего лишь для демонстрации возможности обойтись без "синтаксических нелепостей", как вы имели честь их назвать.

))

Здравствуйте, zaiats_2k, Вы писали:
_>В моём тексте какжется было не совсем так, как вы цитируете: "((1 shl D) and SD)<>0)"...
То, как было у вас в тексте, не будет компилироваться, т.к. во-первых, в Паскале нет синтаксиса С-style cast, а во-вторых, приведение целого к boolean запрещено.
_>И покажите мне, плиз, "типоопасность" в моём коде?

все очень просто. Если у нас D в этом выражении больше, чем sizeof(integer), то код перестанет работать, а компилятор нам об этом ничего не скажет. Исходный код с множествами в этом смысле гораздо безопаснее — там нельзя включить в множество элемент, которого в нем не может быть.
_>Да и предназначен он был всего лишь для демонстрации возможности обойтись без "синтаксических нелепостей", как вы имели честь их назвать.

))
Я все это прекрасно понимаю. Дело в том, что идя по этой дороге, мы придем к пониманию того, что от всех нелепостей лечит ключевое слово asm. Но это возврат в каменный век!
Возвращаясь к теме — речь шла о сравнении длин программ на С++ и на Pascal. При прочих равных выясняется, что длина кода в плюсах будет меньше, т.к. там можно перегружать операторы (а запись a+=b всегда короче, чем a:= Add(a, b)) и операторные скобки занимают в сумме 2 символа ({}) вместо 8 (begin/end). Единственное место, где Delphi лапидарнее — это ключевое слово with. Не думаю, что с его помощью удастся значительно сократить программу, т.к. для большинства его применений в С++ есть альтернативные методы, которые к тому же приводят к более читаемому коду.
Благодаря наличию шаблонов выразительность кода еще повышается, позволяя значительно сократить объем библиотек.
Да, в язык Delphi встроено много паттернов, которые пришлось бы реализовывать вручную на плюсах. Но их проблема в том, что любой отход от паттерна в сторону сразу приводит к раздуванию кода, т.к. каждый из них уникален. Попробуйте хранить доп. информацию о свойствах класса! В язык С++ встроены более мощные средства выражения самих паттернов, что позволяет реализовывать почти всю ту же функциональность самому. Как писал Страуструп — в С++ нет встроенного типа complex, но при нужде его можно определить средствами языка так, чтобы он был не хуже встроенного ни с точки зрения синтаксиса, ни с точки зрения производительности. Там, где Delphi дает рыбу, С++ дает удочку.
Преимуществом Delphi является то, что не нужно особо следить за съедобностью этой рыбы.

... << RSDN@Home 1.1 beta 2 >>

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

S>Здравствуйте, zaiats_2k, Вы писали:
_>>В моём тексте какжется было не совсем так, как вы цитируете: "((1 shl D) and SD)<>0)"...
S>То, как было у вас в тексте, не будет компилироваться, т.к. во-первых, в Паскале нет синтаксиса С-style cast, а во-вторых, приведение целого к boolean запрещено.

Ну ладно, ладно, я уже 3 года не писал на Дельфи, забыл. Там синтаксис такой boolean(I). И приведение не запрещено.

_>>И покажите мне, плиз, "типоопасность" в моём коде?

S>все очень просто. Если у нас D в этом выражении больше, чем sizeof(integer), то код перестанет работать, а компилятор нам об этом ничего не скажет. Исходный код с множествами в этом смысле гораздо безопаснее — там нельзя включить в множество элемент, которого в нем не может быть.

D в нашем случае остаток от деления на 10, и больше 9 он не может быть по определению. А работать оно перестанет не при sizeof(integer)+1, а при sizeof(integer)*8+1

))

S>Возвращаясь к теме — речь шла о сравнении длин программ на С++ и на Pascal. При прочих равных выясняется, что длина кода в плюсах будет меньше, т.к. там можно перегружать операторы (а запись a+=b всегда короче, чем a:= Add(a, b)) и операторные скобки занимают в сумме 2 символа ({}) вместо 8 (begin/end). Единственное место, где Delphi лапидарнее — это ключевое слово with. Не думаю, что с его помощью удастся значительно сократить программу, т.к. для большинства его применений в С++ есть альтернативные методы, которые к тому же приводят к более читаемому коду.

Как тут уже правильно заметили — учить слепой десятипальцевый надо. И тогда длина кода на 15% большая не будет для тебя аргументом. Да и переменные перестанешь называть A, D и SD.

))

S>Благодаря наличию шаблонов выразительность кода еще повышается, позволяя значительно сократить объем библиотек.

Да с этим никто давно уже не спорит, кроме тех кто не может\не хочет разобраться с шаблонами.

S>Да, в язык Delphi встроено много паттернов, которые пришлось бы реализовывать вручную на плюсах. Но их проблема в том, что любой отход от паттерна в сторону сразу приводит к раздуванию кода, т.к. каждый из них уникален. Попробуйте хранить доп. информацию о свойствах класса! В язык С++ встроены более мощные средства выражения самих паттернов, что позволяет реализовывать почти всю ту же функциональность самому. Как писал Страуструп — в С++ нет встроенного типа complex, но при нужде его можно определить средствами языка так, чтобы он был не хуже встроенного ни с точки зрения синтаксиса, ни с точки зрения производительности. Там, где Delphi дает рыбу, С++ дает удочку.

И с этим тоже не спорю.

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

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

S>>Здравствуйте, zaiats_2k, Вы писали:
_>>>В моём тексте какжется было не совсем так, как вы цитируете: "((1 shl D) and SD)<>0)"...
S>>То, как было у вас в тексте, не будет компилироваться, т.к. во-первых, в Паскале нет синтаксиса С-style cast, а во-вторых, приведение целого к boolean запрещено.

_>Ну ладно, ладно, я уже 3 года не писал на Дельфи, забыл. Там синтаксис такой boolean(I). И приведение не запрещено.
Зря вы так думаете.

...The previous remarks refer to the ordinality of Boolean values, not to the values themselves. In Delphi, Boolean expressions cannot be equated with integers or reals. Hence, if X is an integer variable, the statement

if X then ...;

generates a compilation error. Casting the variable to a Boolean type is unreliable, but each of the following alternatives will work.

if X <> 0 then ...; { use longer expression that returns Boolean value }
var OK: Boolean { use Boolean variable }
...
if X <> 0 then OK := True;
if OK then ...;

Delphi 7 Help.

... << RSDN@Home 1.1 beta 2 >>

Здравствуйте, Sinclair, Вы писали:
S>Зря вы так думаете.
S>

S>...The previous remarks refer to the ordinality of Boolean values, not to the values themselves. In Delphi, Boolean expressions cannot be equated with integers or reals. Hence, if X is an integer variable, the statement

S>if X then ...;

S>generates a compilation error. Casting the variable to a Boolean type is unreliable, but each of the following alternatives will work.

S>if X <> 0 then ...; { use longer expression that returns Boolean value }
S>var OK: Boolean { use Boolean variable }
S> ...
S>if X <> 0 then OK := True;
S>if OK then ...;

S>Delphi 7 Help.

Да тут совсем не о том написано. Вот цитата из Language Reference касательно variable typecast:

You can cast any variable to any type, provided their sizes are the same and you do not mix integers with reals. (To convert numeric types, rely on standard functions like Int and Trunc.) Examples of variable typecasts include

Char(I)
Boolean(Count)
TSomeDefinedType(MyVariable)

Касательно Value typecast:

In a value typecast, the type identifier and the cast expression must both be ordinal or pointer types. Examples of value typecasts include

Integer('A')

Char(48)
Boolean(0)
Color(2)
Longint(@Buffer)

The resulting value is obtained by converting the expression in parentheses. This may involve truncation or extension if the size of the specified type differs from that of the expression. The expression’s sign is always preserved.
The statement

I := Integer('A');

assigns the value of Integer('A')—that is, 65—to the variable I.
A value typecast cannot be followed by qualifiers and cannot appear on the left side of an assignment statement.

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

TL>Начинать с нуля WinAPI, принципы работы с БД, C++ и "прочую лабудень" по-моему не стоит. WinAPI во-первых чрезмерно широк и имеет ряд довольно узких специализаций, а во-вторых по слухам предполагается быть упраздненным. Принципы работы с БД в VFP и других системах не особо отличаются. C++ — это вообще отдельная тема, тут я не могу ничего сказать.

TL>Тут вот меня просили "помочь изучить C++". Проект для изучения был о-очень оригинальный: БД на Postgress (так, кажется, пишется) с клиентами на Telnet или что-то такое — я точно не вник. Я попытался объяснить, что подобный проект проще, эффективнее, рациональнее и все такое, делать на Visual Basic, но... Наверное мне еще стоит поучиться риторике. Не знаю как вы, а я, например, просто в шоке от кода ADO под C++

. Вот в VB это просто очаровательно! Но в C++ — нет, увольте!

А мне так не показалось, нормальный код, если приглядеться. Я использую ADO и в VB, и в C++(VC),
шока нет. Выбор языка, ИМХО, зависит от того, сколько тебе заплатят, и сколько времени на разработку.

TL>Это, разумеется, мое скромное мнение, именуемое также ИМХО или IMHO — как кому больше нравится...

Борланд билдер против VC++ — это, что плотник супротив столяра (С)(А.П.Чехов — "Каштанка")

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

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

P>[skip]
HD>>Дельфи — это "RAD System — Rapid application Development System" т.е. система быстрой разработки приложений. нигде не вижу слов про БД... странно... то, что они исхитрились встроить в систему быстрый удобный и универсальный движок работы с БД — честь им и хвала. То, что я видел кучи

P>Спорный вопрос... Особенно насчет удобный...

Целиком и полностью, BDE — это самый страшный грех Борланда перед человечеством

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

S>>Возвращаясь к теме — речь шла о сравнении длин программ на С++ и на Pascal. При прочих равных выясняется, что длина кода в плюсах будет меньше, т.к. там можно перегружать операторы (а запись a+=b всегда короче, чем a:= Add(a, b)) и операторные скобки занимают в сумме 2 символа ({}) вместо 8 (begin/end). Единственное место, где Delphi лапидарнее — это ключевое слово with. Не думаю, что с его помощью удастся значительно сократить программу, т.к. для большинства его применений в С++ есть альтернативные методы, которые к тому же приводят к более читаемому коду.

_>Как тут уже правильно заметили — учить слепой десятипальцевый надо. И тогда длина кода на 15% большая не будет для тебя аргументом. Да и переменные перестанешь называть A, D и SD.

))

Не вижу смысла. Имеем два случая:
1. Я не умею печатать СДП (слепым десятипальцевым) методом — длина кода > на 15%. Время набора 1 символа, допустим == 1 сек. Набор 2х символов — за 2 сек., 8 — за 8 сек.
2. Я умею печатать СДП методом — и что, длина кода уменьшилась? Ну стал я писать 1 символ за 0.5 секунд, что изменилось? 2 символа — 1 сек., 8 — 4 сек.
Что я хочу сказать: при одинаковой скорости печати, главное не скорость, а количество.

... << Posted by RSDN@Home 1.1 beta 2 >>

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

B>Целиком и полностью, BDE — это самый страшный грех Борланда перед человечеством

А вот тут вы не правы. В свое время BDE был прорывом в технологиях. В 1992 году ODBC и рядом с ним не стоял. Впрочем, как и сейчас. Другое дело, что сейчас есть другие технологии доступа к разнородным данным. Которые являются развитием идей BDE. Так что BDE — это не грех Борланда перед человечеством, а заслуга.

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

R3>

Не вижу смысла. Имеем два случая:
R3>1. Я не умею печатать СДП (слепым десятипальцевым) методом — длина кода > на 15%. Время набора 1 символа, допустим == 1 сек. Набор 2х символов — за 2 сек., 8 — за 8 сек.
R3>2. Я умею печатать СДП методом — и что, длина кода уменьшилась? Ну стал я писать 1 символ за 0.5 секунд, что изменилось? 2 символа — 1 сек., 8 — 4 сек.
R3>Что я хочу сказать: при одинаковой скорости печати, главное не скорость, а количество.

Так уже не раз говорили, что на сам процесс написания кода у программиста уходит не так уж много времени (СДП еще больше уменьшает это время). Больше времени уходит на отладку, исследовании проблемы, эксперименты, чтение MSDN-а и форумов, чтение предыдуще написанного кода и т.д.

R3>

Не вижу смысла. Имеем два случая:
R3>1. Я не умею печатать СДП (слепым десятипальцевым) методом — длина кода > на 15%. Время набора 1 символа, допустим == 1 сек. Набор 2х символов — за 2 сек., 8 — за 8 сек.
R3>2. Я умею печатать СДП методом — и что, длина кода уменьшилась? Ну стал я писать 1 символ за 0.5 секунд, что изменилось? 2 символа — 1 сек., 8 — 4 сек.
R3>Что я хочу сказать: при одинаковой скорости печати, главное не скорость, а количество.

СДП среднего уровня это примерно 250 симв/мин, итого имеем 0.24 сек на символ.

Но дело тут не в скорости даже, а в том, что без СДП попросту напрягает набирать длинные слова, а в результате снижается читабельность кода.
Опять же писать приходится не только код, но и документацию. А смею вас уверить это два совсем разных случая. Одно дело когда ты думаешь что написать, а пальцы сами это выстукивают, и совсем другое когда постоянно взгляд перемещается с клавиатуры на экран. Да и для зрения не слишком полезны подобные упражнения.

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

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

B>>Целиком и полностью, BDE — это самый страшный грех Борланда перед человечеством

FWP>А вот тут вы не правы. В свое время BDE был прорывом в технологиях. В 1992 году ODBC и рядом с ним не стоял. Впрочем, как и сейчас. Другое дело, что сейчас есть другие технологии доступа к разнородным данным. Которые являются развитием идей BDE. Так что BDE — это не грех Борланда перед человечеством, а заслуга.
За Парадокс им тоже медаль?

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

B>>Целиком и полностью, BDE — это самый страшный грех Борланда перед человечеством

, то погода нелетная

. Знакомые, кто под Дельфей и Билдером сидит, отказились от него в пользу ADO. В 1992 году я под DOS на TurboC писал, а также на Clipper(помидорами прошу не кидаться, особенно тухлыми

). В Win3.11 for WG на FoxPro 2.6 работал, под Win32 на MS VC++ к базам, сначало с помощью ODBC, а затем и ADO

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

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

S>Часто приходится слышать мнение, что разработчики, использующие delphi -
S>ваще не программисты, а так... детишки неразумные.
S>Ясно, что у нее (как и у каждого ср-ва разработки) есть свои минусы,
S>но и плюсы тоже имеются. Я, например, юзаю с равной интенсивностью и
S>delphi, и vc++, и MASM. И что, об этом лучше никому не говорить?
S>По-вашему, чем вызвано такое негативное отношение?

ИМХО все эти обсуждения рождены во многом существующей разницей в оплате труда программистов, использующих тот или иной инструмент. Не скажу ничего нового: С++/Java является промышленным стандартом. Соответственно, используя C++/Java больше (против Delphi) вероятность работы на иностранного заказчика, а там обычно и з.платы больше. Отсюда вывод: на C++/Java пишут настоящие, а на Delphi — менее настоящие программеры.

То же самое про VisualC++ и С++Builder. Большинство выбирает VisualC++ не потому, что он "лучше во 100 раз", а потому, что вариант беспроигрышный в плане долгосрочной перспективы (MS точно не развалится и не перестанет поддерживать свои компиляторы). А Borland... посмотрите на C++BuilderX. Отсюда и флеймы всякие типа: Builder — это и не C++ вовсе, а чистый С++ — это MSVC. На самом-то деле спор идет не о языках программирования и не библиотеках ("дубовая VCL против гибкой MFC"), а долгосрочной перспективе использования продукции фирмы Borland vs Microsoft, где первая явно проигрывает.

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

Скажу как человек писавший на билдере и вижуле(я еще и на дельфе писал но давно это было). Такого колличества глюков как в билдере я ни где не видел

от падающего на copy/paste IDE и дебугер которого можно уронить исключением до ошибок кодогенерации и не корректной работы с const.

ЗЫ на билдер я могу долго материться.

ЗЗЫ на дельфи еще дольше. Ибо ни чего этот язык не умеет.

ЗЗЗЫ а как ты думаешь почему С++ и жаба это промышленные стандарты?

... << RSDN@Home 1.1 beta 2 >>

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

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

WH>Скажу как человек писавший на билдере и вижуле(я еще и на дельфе писал но давно это было). Такого колличества глюков как в билдере я ни где не видел

от падающего на copy/paste IDE и дебугер которого можно уронить исключением до ошибок кодогенерации и не корректной работы с const.

5-6 версии ИМХО стабильно работают

WH>ЗЫ на билдер я могу долго материться.

WH>ЗЗЫ на дельфи еще дольше. Ибо ни чего этот язык не умеет.

WH>ЗЗЗЫ а как ты думаешь почему С++ и жаба это промышленные стандарты?

Жаба — потому что за ними стоят Sun+IBM+Oracle & Co. С++ — естественным путем (ибо не было ни жабы ни Delphi ни ..., компьютеры были большими и был лишь C++ — преемник C), стар уже. Ну а в свое время просто был поддержан большинством производителей ПО и ОС как пришедший на смену С и являющийся эффективной реализацией ООП.

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

Y>>Извиняйте за небольшой офтопик, что Вы, уважаемые гуру межете сказать плохого
Y>>про C#, если уже сравнивать его с Delphi и C.

iT>Гуру — не гуру, но скажу

iT>Мне например, немножко не нравится взятая из java схема, когда тело метода нельзя оторвать от его декларации... В паскале есть interface/implementation и это красиво. В C/C++ есть хедеры — тоже разнесены интерфейс и реализация...

ИМХО отказ от разделения декларации и реализации ухудшает возможности разбиения на модули гораздо больше чем в Delphi по сравнению с C++. На что у изобретателей Java есть стандартный ответ : "если правильно проектировать ...".

от падающего на copy/paste IDE и дебугер которого можно уронить исключением до ошибок кодогенерации и не корректной работы с const.

WH>ЗЫ на билдер я могу долго материться.

WH>ЗЗЫ на дельфи еще дольше. Ибо ни чего этот язык не умеет.

WH>ЗЗЗЫ а как ты думаешь почему С++ и жаба это промышленные стандарты?

WH>ЗЗЫ на дельфи еще дольше. Ибо ни чего этот язык не умеет.

— слова человека, который слабо представляет о чем говорит...

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

ST>5-6 версии ИМХО стабильно работают
Дык я на шестой со всеми сревиспаками и работаю....

Тут я кое что перечислил. Заметь представитель борданд читающий ту ветку мой пост проигнорировал те косвенно подтвердил если бы этих проблем небыло то я уверен что былбы опровергающий пост.

ST>Жаба — потому что за ними стоят Sun+IBM+Oracle & Co.
Хм. А я то тумал что это кроссплатформенный динамический язык, а тут оказывается...
ST>С++ — естественным путем (ибо не было ни жабы ни Delphi ни ...,
Хм. Если мне не изменяет скалероз то паскакль появился раньше чем С++.
ST>компьютеры были большими и был лишь C++ — преемник C), стар уже. Ну а в свое время просто был поддержан большинством производителей ПО и ОС как пришедший на смену С и являющийся эффективной реализацией ООП.
Типа в дельфе ООП реализовано лучше

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

WH>>ЗЗЫ на дельфи еще дольше. Ибо ни чего этот язык не умеет.

AK>- слова человека, который слабо представляет о чем говорит...
Слова человека который слабо представляет с кем говорит

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

ST>>Жаба — потому что за ними стоят Sun+IBM+Oracle & Co.
WH>Хм. А я то тумал что это кроссплатформенный динамический язык, а тут оказывается...

ИМХО Вы ошибались

WH>Типа в дельфе ООП реализовано лучше

Есть некоторые вещи, касающиеся ООП, которые действительно лучше реализованы в дельфе. Как, например, вызов виртуальных функций из конструктора, RTTI (ну и, как следствие, виртуальные конструкторы)...

Мысль же моя в основном сводилась к тому, что борьба между различными конторами идет не за то, чтобы мы с Вами использовали что-то лучшее, а за то, кто деньги будет получать. Прогресс же тут как следствие и вовсе не обязательно именно прогресс (м.б. и обратно придем).

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

WH>Тут я кое что перечислил.
->Заметь представитель борданд читающий ту ветку мой пост проигнорировал те косвенно подтвердил
->если бы этих проблем небыло то я уверен что былбы опровергающий пост.
-----------
1. Preview-версии продуктов обычно не комментируются. Для этого существуют конференции филд-тестеров.
2. К сожалению, вдаваться в детали проблем, идентифицируемых как "у меня в подвале стук" не представляется возможным.
3. Код, демонстрирующий проблемы, в отношении которого принято применять в эхо-конференциях фразу "в студию", в случае уверенности, что "половина багов не моя" должен адресоваться службе технической поддержки.

С уважением,
Сергей Орлик
Borland

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

WH>Скажу как человек писавший на билдере и вижуле(я еще и на дельфе писал но давно это было). Такого колличества глюков как в билдере я ни где не видел

от падающего на copy/paste IDE и дебугер которого можно уронить исключением до ошибок кодогенерации и не корректной работы с const.
IDE и дебугер работают идеально (почти). Насчёт ошибок кодогенерации — согласен (для C++Builder4), насчёт const — приведи пример.

WH>ЗЫ на билдер я могу долго материться.

Я бы посмотрел на тебя, как ты бы стал материться, если в твоём проекте было больше полсотни разнообразных окошек и ты бы всё это делал на VS (без привязки к .net). Причём каждую неделю заказчик просил бы что-нибудь переделать в интерфейсе.

WH>ЗЗЫ на дельфи еще дольше. Ибо ни чего этот язык не умеет.

... << RSDN@Home 1.1 beta 1 >>

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

ST>Есть некоторые вещи, касающиеся ООП, которые действительно лучше реализованы в дельфе. Как, например, вызов виртуальных функций из конструктора,
В дельфе нет конструкторов в том виде в котором они есть в С++. В дельфе это фабричная функция

struct base
{
    static base* create()
    {
        base* ptr=new base;
        ptr->create_();
        return ptr;
    }
    void create_()
    {//Тело конструктора
        fn();
    }
    virtual //надо если деструктор виртуальный
    void destroy()
    {
        destroy_();
        delete this;
    }
    void destroy_()
    {//Тело деструктора
    }
    virtual void fn()=0;
};
struct some
    :base
{
    static some* create()
    {
        some* ptr=new some;
        ptr->create_();
        return ptr;
    }
    void create_()
    {//Тело конструктора
        base::create_();
    }
    virtual //надо если деструктор виртуальный
    void destroy()
    {
        destroy_();
        delete this;
    }
    void destroy_()
    {//Тело деструктора
        base::destroy_();
    }
    virtual void fn()
    {//Та самая виртуальная функция которую можно вызвать из базового конструктора.
    }
};

Можно еще набросать пару макросов и

/*****************************************************/
#define delphi_ctor_p(name, params, in_params)\
    static name* create params\
    {\
        std::auto_ptr<name> _p_t_r_(new name);\
        _p_t_r_->ctor in_params ;\
        return _p_t_r_.release();\
    }\
    void ctor params \
/*****************************************************/
#define delphi_ctor(name)\
    delphi_ctor_p(name, (), ())\
/*****************************************************/
#define delphi_dtor(name)\
    void destroy()\
    {\
        std::auto_ptr<name> _p_t_r_(this);\
        dtor();\
    }\
    void dtor()\
/*****************************************************/
struct base
{
    delphi_ctor(base)
    {
        fn();
    }
    delphi_ctor_p(base, (float gg, float ggg), (gg, ggg))
    {
        ctor();
    }
    delphi_dtor(base)
    {
        fn();
    }
    virtual void fn()
    {
        std::cout<<"base::fn";
    }
};
struct some
    :base
{
    delphi_ctor(some)
    {
        base::ctor();
    }
    delphi_ctor_p(some, (int gg), (gg))
    {
        base::ctor();
    }
    delphi_ctor_p(some, (float gg, float ggg), (gg, ggg))
    {
        base::ctor(gg, ggg);
    }
    delphi_dtor(some)
    {
        base::dtor();
    }
    virtual void fn()
    {
        std::cout<<"some::fn\n";
    }
};

int main()
{
    some* ptr=some::create(2, 4);
    ptr->destroy();
    return 0;
}

Вывод

some::fn
some::fn

О уже почти дельфя. Вернее логически один в один.
Перед delphi_dtor можно поставить virtual и деструктор станет виртуальным.
Еще вопросы?
ST>RTTI
Ну в С++ оно теже есть. Конечно список пропертей из паблишед не получить да и в С++ пиблишед нету но для работы вполне достаточно.
ST>(ну и, как следствие, виртуальные конструкторы)...
Нафиг не надо абстрактные фабрики прекрасно справляются.

ST>Мысль же моя в основном сводилась к тому, что борьба между различными конторами идет не за то, чтобы мы с Вами использовали что-то лучшее, а за то, кто деньги будет получать. Прогресс же тут как следствие и вовсе не обязательно именно прогресс (м.б. и обратно придем).
Ну это уже очень глубоко филосовские темы. Но я считаю что прогресс идет из-за двух вещей
1)Лень
Людям лениво было помнить машинные коды — придумали асм
Потом стало лениво писать на асме — придумали С
...
2)Зарабатывание денег/славы/продолжить по вкусу
Без коментариев.

... << RSDN@Home 1.1 beta 2 >>

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

Тут можно немного проще сделать

/*****************************************************/
#define delphi_class(name)\
private:\
    typedef name this_type;\
public:\
/*****************************************************/
#define delphi_ctor_p(params, in_params)\
    static this_type* create params\
    {\
        std::auto_ptr<this_type> _p_t_r_(new this_type);\
        _p_t_r_->ctor in_params ;\
        return _p_t_r_.release();\
    }\
    void ctor params \
/*****************************************************/
#define delphi_ctor()\
    delphi_ctor_p((), ())\
/*****************************************************/
#define delphi_dtor()\
    void destroy()\
    {\
        std::auto_ptr<this_type> _p_t_r_(this);\
        dtor();\
    }\
    void dtor()\
/*****************************************************/
struct base
{
    delphi_class(base)
    delphi_ctor()
    {
        fn();
    }
    delphi_ctor_p((float gg, float ggg), (gg, ggg))
    {
        ctor();
    }
    delphi_dtor()
    {
        fn();
    }
    virtual void fn()
    {
        std::cout<<"base::fn";
    }
};
struct some
    :base
{
    delphi_class(some)
    delphi_ctor()
    {
        base::ctor();
    }
    delphi_ctor_p((int gg), (gg))
    {
        base::ctor();
    }
    delphi_ctor_p((float gg, float ggg), (gg, ggg))
    {
        base::ctor(gg, ggg);
    }
    delphi_dtor()
    {
        base::dtor();
    }
    virtual void fn()
    {
        std::cout<<"some::fn\n";
    }
};

Особенно хорошо будет если имя класса длинное

... << RSDN@Home 1.1 beta 2 >>

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

B>За Парадокс им тоже медаль?

От Парадокса Borland отказалась еще в 1993-м. Да и кроме Paradox у них ведь еще DBASE и InterBase были.

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

СО>3. Код, демонстрирующий проблемы, в отношении которого принято применять в эхо-конференциях фразу "в студию", в случае уверенности, что "половина багов не моя" должен адресоваться службе технической поддержки.
Исполнитель BCB6

Скомпилил

хоть варнинг дал и на том списибо.

struct test
{
    void fn()
    {
    }
    void fn2()
    {
        fn();
    }
    void fn2()const
    {
        fn();
    }
};

Поню еще чтото было но что именно забыл.

А как вам такое?

struct test
{
    test()
    {
        ShowMessage("ctor");
    }
    test(const test&)
    {
        ShowMessage("cctor");
    }
    test& operator=(const test&)
    {
        ShowMessage("assign");
        return *this;
    }
    ~test()
    {
        ShowMessage("dtor");
    }
    operator bool()
    {
        return false;
    }
};

__fastcall TForm1::TForm1(TComponent* Owner)
    : TForm(Owner)
{
    while(test t=test())
    {
    }
}

Вывод ctor dtor dtor

__fastcall TForm1::TForm1(TComponent* Owner)
    : TForm(Owner)
{
    try
    {
        int i=0;
        while(i<10)
        {
            if(test t=test())
                continue;
            ++i;
        }
    }
    catch(...){}
}

[C++ Error] Unit1.cpp(45): E2202 Goto into an exception handler is not allowed

А так компилится

__fastcall TForm1::TForm1(TComponent* Owner)
    : TForm(Owner)
{
    try
    {
        int i=0;
        while(i<10)
        {
            if(i==5)
                continue;
            ++i;
        }
    }
    catch(...){}
}

Остальные так с ходу востроизвести не удалось но честное слово я их видел.

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

FWP>>А вот тут вы не правы. В свое время BDE был прорывом в технологиях. В 1992 году ODBC и рядом с ним не стоял. Впрочем, как и сейчас. Другое дело, что сейчас есть другие технологии доступа к разнородным данным. Которые являются развитием идей BDE. Так что BDE — это не грех Борланда перед человечеством, а заслуга.

B>Да кривой он до ужаса, часто приходилось с 5 версией мучиться, то левел не тот

, то погода нелетная

.
Про какой-такой Level. Уж не с FoxPro ли вы работаете? Какой ужас

B>Знакомые, кто под Дельфей и Билдером сидит, отказились от него в пользу ADO.
Какое ADO в 1995 году? А сейчас другое дело. Сами Borland рекомендуют ADO под Win и DBExpress для кросплатформенной разаработки.

B> В 1992 году я под DOS на TurboC писал, а также на Clipper(помидорами прошу не кидаться, особенно тухлыми

). В Win3.11 for WG на FoxPro 2.6 работал, под Win32 на MS VC++ к базам, сначало с помощью ODBC, а затем и ADO

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

Я тот же путь проделал

И ничего хуже FoxPro не видел. Но это не самый большой грех MS. Самый большой — Windows

Это "моё личное мнение, задеть ни кого не хотел

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

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

ST>>Есть некоторые вещи, касающиеся ООП, которые действительно лучше реализованы в дельфе. Как, например, вызов виртуальных функций из конструктора,
WH>В дельфе нет конструкторов в том виде в котором они есть в С++. В дельфе это фабричная функция

Дык и не нужно конструктора в том виде — все равно он ничего не конструирует (вся работа в операторе new происходит) — просто как триггер на создание объекта различными способами используется и все.

WH>

WH>struct base
WH>{
<skipped>

WH>some::fn
WH>

WH>О уже почти дельфя. Вернее логически один в один.
WH>Перед delphi_dtor можно поставить virtual и деструктор станет виртуальным.
WH>Еще вопросы?

Это даже не интересно. Любую логику можно и на ассемблере реализовать. Интересно то, что уже реализовано, является стандартом для данного языка и не надо руками мучать.

ST>>RTTI
WH>Ну в С++ оно теже есть. Конечно список пропертей из паблишед не получить да и в С++ пиблишед нету но для работы вполне достаточно.
ST>>(ну и, как следствие, виртуальные конструкторы)...
WH>Нафиг не надо абстрактные фабрики прекрасно справляются.

Ничего прекрасного в них нет — просто затычка.

ST>>Мысль же моя в основном сводилась к тому, что борьба между различными конторами идет не за то, чтобы мы с Вами использовали что-то лучшее, а за то, кто деньги будет получать. Прогресс же тут как следствие и вовсе не обязательно именно прогресс (м.б. и обратно придем).
WH>Ну это уже очень глубоко филосовские темы.
см. тему форума

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

ST>Дык и не нужно конструктора в том виде — все равно он ничего не конструирует

ST>(вся работа в операторе new происходит) —

ST>просто как триггер на создание объекта различными способами используется и все.

Ну уж нет. В С++ это конструктор, а вот в дельфе это лишь функция вызваная после полного создания объекта. И только по этому там можно вызывать виртуальные функции ибо объект уже давно создан.

ST>Это даже не интересно. Любую логику можно и на ассемблере реализовать. Интересно то, что уже реализовано, является стандартом для данного языка и не надо руками мучать.
Мдя. Я реализовал логически эквивалентные дельфе конструкторы/деструкторы на С++, а мне говорят что это даже не интересно.

ST>Ничего прекрасного в них нет — просто затычка.
Ага. Единственный аргумент тех кому нечего сказать.

... << RSDN@Home 1.1 beta 2 >>

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

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

ST>>Дык и не нужно конструктора в том виде — все равно он ничего не конструирует
WH>

ST>>(вся работа в операторе new происходит) —
WH>

ST>>просто как триггер на создание объекта различными способами используется и все.
WH>

Ну уж нет. В С++ это конструктор, а вот в дельфе это лишь функция вызваная после полного создания объекта. И только по этому там можно вызывать виртуальные функции ибо объект уже давно создан.

А как в конструкторе C++ можно управлять созданием объекта ?

WH>Мдя. Я реализовал логически эквивалентные дельфе конструкторы/деструкторы на С++, а мне говорят что это даже не интересно.

Ну, я извиняюсь, если это показалось грубым.

Но, право же, это правда, ибо реализовать это можно 10 разными способами, а в стандарте нет ни одного — т.е. самодеятельность получается.

WH>Ага. Единственный аргумент тех кому нечего сказать.

да пребудет мир с Вами

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

DG>Во-первых, я имел ввиду большую (но все таки не всю) часть дельфистов.
DG>Во-вторых, если завтра взять двух достаточно умных людей, но которые не разбираются в программировании,
DG>и посадим их писать проги на Delphi, и на VC, то второму придется (хошь, не хошь) выучить больше о программирование, чем первому.

Хороший аргумент! Полностью поддерживаю!

Э... можно небольшое уточнение? А в чью только пользу этот аргумент?

Здравствуйте, WolfHound, Вы писали:
Ну, теперь еще сделай так, чтобы я мог построить функцию, принимающую указатель на класс и вызывающую вот этот твой сreate с заданными параметрами.
В дельфи это будет вот так:

type
  TBaseClass = class of base;
function CreateMyBaseDescendant(BaseClass: TBaseClass): base;
begin
  Result:= BaseClass.create(2, 4);
end;
var
  K: base;
begin
  K:= CreateMyBaseDescendent(some);
end;

... << RSDN@Home 1.1 beta 2 >>

DG>>и посадим их писать проги на Delphi, и на VC, то второму придется (хошь, не хошь) выучить больше о программирование, чем первому.

Пожалуй. Но мне кажется, что быстрее и качественнее программу напишет первый.

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

DG>>>и посадим их писать проги на Delphi, и на VC, то второму придется (хошь, не хошь) выучить больше о программирование, чем первому.

iT>Пожалуй. Но мне кажется, что быстрее и качественнее программу напишет первый.

Ну и еще, что имхо не менее важно при работе с клиентами, красивее, привлекательнее, дружественнее. Знаю по личному опыту. Хотя сразу оговорюсь — это также сильно зависит от непосредственного исполнителя и постановщика задачи.

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

DG>>>и посадим их писать проги на Delphi, и на VC, то второму придется (хошь, не хошь) выучить больше о программирование, чем первому.

iT>Пожалуй. Но мне кажется, что быстрее и качественнее программу напишет первый.

Опыт показывает что нет. Быстрее — да. Качественее — НЕТ. Ламер садится за Дельфи, понимает что кидать кнопки на форму и настраивать пропертя это очень просто. Кое-как лабает программу худо-бедно работающую и на этом останавливается в развитии.

На VC так не получается. Там думать надо, усилия прикладывать... Соответственно и результаты лучше получаются в конечном счёте.

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

_>Здравствуйте, Igor Trofimov, Вы писали:

DG>>>>и посадим их писать проги на Delphi, и на VC, то второму придется (хошь, не хошь) выучить больше о программирование, чем первому.

iT>>Пожалуй. Но мне кажется, что быстрее и качественнее программу напишет первый.

_>Опыт показывает что нет. Быстрее — да. Качественее — НЕТ. Ламер садится за Дельфи, понимает что кидать кнопки на форму и настраивать пропертя это очень просто. Кое-как лабает программу худо-бедно работающую и на этом останавливается в развитии.

На VC так не получается. Там думать надо, усилия прикладывать... Соответственно и результаты лучше получаются в конечном счёте.

Давайте все же не будем считать ламеров программистами — последним обидно. Ламер — он и в Африке ламер, хоть на Delphi, хоть на VC. Если человек хочет научиться чему-то по настоящему и будет работать, то он научиться, если нет — то ... что ж делать, насильно не заставишь.

Насчет того, что второму придется выучить больше — полностью согласен. Первому тоже придется выучить не меньше, но позже. Для нормальной работы на Delphi тоже необходимо много знать.

Могу рассказать из личного опыта, если кому интересно.
Начинал со старого доброго Borland Pascal — не было под рукой С и преподы Pascal в универе давали. Работал стандартно через процедуры. В использовании объектов и надобности не возникало — так пробовал для личного развития и только.
Подвернулось задание — попробовал Дельфи 3. Сначало кнопочки, там события, перестраивал себя, учил язык и среду, нарабатывал опыт.
С каждым разом проги получались все лучше и лучше.
Заказов сейчас — куча.От того, что делаю пользователи и клиенты в восторге. (Сужу по отзывам и личным благодарностям. Наездов на проги никаких не было за все время. Только прозьбы добавить чего-нибудь).
Знавал нескольких людей, которые пошли в сторону C++. Как людей — уважаю. Только нос почему-то задирают и усмехаются когда узнают на чем пишу. Однако это вовсе не мешало им просить написать для них программки, алгоритмики, да и за советами дорогу не забывают. И на проги их кстати нареканий было море. (У нас в конторе заказ делали им).

К чему все это говорю? Да к тому, что все равно на каком языке писать — главное, чтобы все работало и работать с программой было удобно и приятно. А там — хоть свой язык пиши, если конечно заказчика сроки и суммы удовлетворять будут, но это уже совсем другая история.

Считаю споры и взаимные доказательства, по поводу Delphi vs VC vs Prolog vs Java vs VB vs etc., читай подоплеку — "Я круче..." или "Да вы полные дауны и ламеры..." абсолютно бестолковые и ничего кроме лишней трепке нервов не несут. Хотя конечно имхо.

Может лучше сообща придумать перечень требований, которые хотелось бы видеть в "Идеальном Языке Программирования" или "Идеальной Среде Программирования". К терминам прозьба не придираться — они в принципе не важны.

P.S.
Сейчас работаю на Delphi 6, активно использую ООП и всякое другое, че там есть. Практически полностью доволен и языком и средой. Не хватает мелочей. Хотя не исключаю возможности, что они уже есть а я просто не знаю где их найти. Крайне уважительно отношусь к другим языкам. Стараюсь также относиться к программистам, которые на них пишут.

2: zaiats_2k> Прошу прощения за такой монолог в ответе — это не наезд, просто не знаю в какую ветку кинуть.

С уважением.

Z2>Опыт показывает что нет. Быстрее — да. Качественее — НЕТ. Ламер садится за Дельфи, понимает что кидать кнопки на форму и настраивать пропертя это очень просто. Кое-как лабает программу худо-бедно работающую и на этом останавливается в развитии.

На VC так не получается. Там думать надо, усилия прикладывать... Соответственно и результаты лучше получаются в конечном счёте.

То же можно и про asm сказать.

"Ламер садится за VC,... Кое-как лабает программу худо-бедно работающую и на этом останавливается в развитии. На asm так не получается. Там думать надо, усилия прикладывать... Соответственно и результаты лучше получаются в конечном счёте."

Переходим на асм? Программы будут просто зашибись!

... << RSDN@Home 1.0 beta 7a >>

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

Z2>>Опыт показывает что нет. Быстрее — да. Качественее — НЕТ. Ламер садится за Дельфи, понимает что кидать кнопки на форму и настраивать пропертя это очень просто. Кое-как лабает программу худо-бедно работающую и на этом останавливается в развитии.

На VC так не получается. Там думать надо, усилия прикладывать... Соответственно и результаты лучше получаются в конечном счёте.

F>То же можно и про asm сказать.

F>
F>"Ламер садится за VC,... Кое-как лабает программу худо-бедно работающую и на этом останавливается в развитии. На asm так не получается. Там думать надо, усилия прикладывать... Соответственно и результаты лучше получаются в конечном счёте."

F>Переходим на асм? Программы будут просто зашибись!
Что ASM? Давайте лучше машинные коды или сразу схемные решения

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

WH>В дельфе нет конструкторов в том виде в котором они есть в С++. В дельфе это фабричная функция
Если вы думаете, что программирование заканчивается на Windows и OLE, то вы несколько заблуждаетесь.

ST>>RTTI
WH>Ну в С++ оно теже есть. Конечно список пропертей из паблишед не получить да и в С++ пиблишед нету но для работы вполне достаточно.
Принимается! Замечательный ответ. Только когда вам отвечают таким же образом реакция почему-то другая

WH>Ну это уже очень глубоко филосовские темы. Но я считаю что прогресс идет из-за двух вещей
WH>1)Лень
WH>Людям лениво было помнить машинные коды — придумали асм
WH>Потом стало лениво писать на асме — придумали С
WH>...
Согласен. Только уж пожалуйста продолжай, раз начал...

Потом стало лениво писать на С — придумали С++
Потом стало лениво писать на С++ — придумали ... Что придумали?

WH>>Людям лениво было помнить машинные коды — придумали асм
WH>>Потом стало лениво писать на асме — придумали С
WH>>...
FWP>Согласен. Только уж пожалуйста продолжай, раз начал...

FWP>Потом стало лениво писать на С — придумали С++
FWP>Потом стало лениво писать на С++ — придумали ... Что придумали?

С#

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

WH>>В дельфе нет конструкторов в том виде в котором они есть в С++. В дельфе это фабричная функция
FWP>Если вы думаете, что программирование заканчивается на Windows и OLE, то вы несколько заблуждаетесь.

Ты вобще о чем?

WH>>Ну в С++ оно теже есть. Конечно список пропертей из паблишед не получить да и в С++ пиблишед нету но для работы вполне достаточно.
FWP>Принимается! Замечательный ответ. Только когда вам отвечают таким же образом реакция почему-то другая

И для чего кроме ГУИ это полезно? Вот толко не надо про сериализацию я на С++ и круче могу.

FWP>Потом стало лениво писать на С — придумали С++
FWP>Потом стало лениво писать на С++ — придумали ... Что придумали?
.NET

... << RSDN@Home 1.1 beta 2 >>

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

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

FWP>>Потом стало лениво писать на С++ — придумали ... Что придумали?
WH>.NET

Жабу придумали раньше. И, судя по срокам, на C++ очень быстро надоело писать

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

Я так и не понял как же конструктор C++ конструирует объект и какие преимущества по сравнению с дельфи это дает ?

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

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

ST>Я так и не понял как же конструктор C++ конструирует объект и какие преимущества по сравнению с дельфи это дает ?

Как ему напишешь, так и конструирует. Можно даже собстветнный менеджер памяти залудить... Смогёшь это в Дельфи повторить?

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

ST>Я так и не понял как же конструктор C++ конструирует объект и какие преимущества по сравнению с дельфи это дает ?
Сначала конструируются базовае классы в порядке перечисления, потом челены класса в порядке обьявления потом происходит вызов тела конструктора причем можно передать параметры в любой из конструкторов как бызовах классов так и челенов.
Уничтожение происходит в обратном порядке те сначала происходит вызов деструктора, потом вызов деструкторов челенов в обратном порядке, потом вызов деструкторов базовых классов в обратном порядке.
Это дает прибавку к скорости в сложных объектах и уменьшает возможности для ошибки и сокращает код.
Например нам надо иметь челен класса динамический массив состоящий из 100 целых чисел и пустой список строк

struct some
{
    std::vector<int> vec;
    std::list<std::string> string_list;
    some()
        :vec(100)
    {}
};

В данном случае гарантировано что массив после создания будет обнулен, а во время разрушения объекта будет корректно удален, тоже самое для списка строк.

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

_>Здравствуйте, s.ts, Вы писали:

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

ST>>Я так и не понял как же конструктор C++ конструирует объект и какие преимущества по сравнению с дельфи это дает ?

_>Как ему напишешь, так и конструирует. Можно даже собстветнный менеджер памяти залудить... Смогёшь это в Дельфи повторить?

В дельфе есть NewInstance, InitInstance, FreeInstance и свой менеджер памяти делается запросто.

Например получение экземпляра Singleton не отличается от получения объекта любого другого класса — при помощи того же конструктора, а не

 static MyClass & _Instance();

Впрочем, того же можно достичь и в С++ путем перегрузки new и delete если гарантировать, что экземпляры будут создаваться только с их помощью. Так ? Или я чего-то не понимаю ?

Но как из конструктора C++ сделать так, чтобы локальный объект располагался в нужном месте, а не в стеке ?


class MyClass
{
private:
  int[100000] Data; 
public:
  MyClass()
  {
    // 2 WolfHound
    // Insert your code here
  };
};

void main(void)
{
  MyClass m;
    // 2 WolfHound
    //<< Предположим, что я хочу, чтобы m располагался в куче ? Что нужно написать в конструкторе ?
};

P.S. Только не нужно делать оберток для MyClass. Мы обсуждаем конструирование объектов в конструкторе.

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

ST>

ST>class MyClass
ST>{
ST>private:
ST>  int Data[100000]; 
ST>public:
ST>  MyClass()
ST>  {
ST>    // 2 WolfHound
ST>    // Insert your code here
ST>  };
ST>};
ST>void main(void)
ST>{
ST>  MyClass m;
ST>    // 2 WolfHound
ST>    //<< Предположим, что я хочу, чтобы m располагался в куче ? Что нужно написать в конструкторе ?
ST>};
ST>

Если хочешь чтобы m было в куче то и создавай его в куче.

int main()
{
    std::auto_ptr<MyClass> m(new MyClass);
    return 0;
};

Если хочешь чтобы этот здоровый массив был в куче то и создавай его в куче

class MyClass
{
private:
  std::vector<int> Data; 
public:
  MyClass()
    :Data(100000)
  {};
};
int main()
{
    MyClass m;
    return 0;
};

Какие проблемы?

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

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

ST>>

ST>>class MyClass
ST>>{
ST>>private:
ST>>  int Data[100000]; 
ST>>public:
ST>>  MyClass()
ST>>  {
ST>>    // 2 WolfHound
ST>>    // Insert your code here
ST>>  };
ST>>};
ST>>void main(void)
ST>>{
ST>>  MyClass m;
ST>>    // 2 WolfHound
ST>>    //<< Предположим, что я хочу, чтобы m располагался в куче ? Что нужно написать в конструкторе ?
ST>>};
ST>>

WH>Если хочешь чтобы m было в куче то и создавай его в куче.
WH>

WH>int main()
WH>{
WH>    std::auto_ptr<MyClass> m(new MyClass);
WH>    return 0;
WH>};
WH>

WH>Если хочешь чтобы этот здоровый массив был в куче то и создавай его в куче
WH>

WH>class MyClass
WH>{
WH>private:
WH>  std::vector<int> Data; 
WH>public:
WH>  MyClass()
WH>    :Data(100000)
WH>  {};
WH>};
WH>int main()
WH>{
WH>    MyClass m;
WH>    return 0;
WH>};
WH>

WH>Какие проблемы?

Такой ответ меня не устраивает. Мы же говорили о том, что конструктор C++ конструирует объекты. Вот и приведи мне пример того, как это сделать. auto_ptr — это доп. обертка.
Код, приведенный выше на любом ОО языке можно написать и не показывает ЧЕМ КОНСТРУКТОР С++ ОТЛИЧАЕТСЯ ОТ ТРИГГЕРА НА СОЗДАНИЕ ОБЪЕКТА.

1.КАК В С++ ИЗ КОНСТРУКТОРВА МОЖНО УПРАВЛЯТЬ КОНСТРУИРОВАНИЕМ ОБЪЕКТА, КРОМЕ ИНИЦИАЛИЗАЦИИ ПОЛЕЙ И ВЫЗОВОВ КОНСТРУКТОРОВ БАЗОВЫХ КЛАССОВ ????????????
2.ЧЕМ ИМЕННО МОЖНО УПРАВЛЯТЬ В КОНСТРУКТОРЕ ????????????????

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

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

ST>>Я так и не понял как же конструктор C++ конструирует объект и какие преимущества по сравнению с дельфи это дает ?
WH>Сначала конструируются базовае классы в порядке перечисления, потом челены класса в порядке обьявления потом происходит вызов тела конструктора причем можно передать параметры в любой из конструкторов как бызовах классов так и челенов.

В делфе нужно указывать вызов конструктора/деструктора базового класса, но в любом месте, а можно и не указывать.

WH>Уничтожение происходит в обратном порядке те сначала происходит вызов деструктора, потом вызов деструкторов челенов в обратном порядке, потом вызов деструкторов базовых классов в обратном порядке.
WH>Это дает прибавку к скорости в сложных объектах и уменьшает возможности для ошибки и сокращает код.

Прибавки в скорости перечисленное выше, конечно же не дает никакой

Видимо, пора наше обсуждение конструкторов заканчивать

Как резюме, от себя могу сказать, чтоо ИМХО конструкторы в дельфи — более сильная часть чем в С++. А чего не хватает относительно С++ — это краткости кода (begin, end etc.), перегрузки операторов и шаблонов. Впрочем, это, видимо, общая тенденция. Ну и еще технологии не хватает (т.е. она кое-как реализуется при поддержке 3-х фирм и очень слабо).

Здравствуйте, s.ts, Вы писали:
ST>Код, приведенный выше на любом ОО языке можно написать и не показывает ЧЕМ КОНСТРУКТОР С++ ОТЛИЧАЕТСЯ ОТ ТРИГГЕРА НА СОЗДАНИЕ ОБЪЕКТА.
Ну, ни в одном ООЯП я не видел такого понятия, как "триггер на создание объекта". Поэтому не могу сказать,чем они отличаются.
ST>1.КАК В С++ ИЗ КОНСТРУКТОРВА МОЖНО УПРАВЛЯТЬ КОНСТРУИРОВАНИЕМ ОБЪЕКТА, КРОМЕ ИНИЦИАЛИЗАЦИИ ПОЛЕЙ И ВЫЗОВОВ КОНСТРУКТОРОВ БАЗОВЫХ КЛАССОВ ????????????
Не кричи. Ответ — никак.
ST>2.ЧЕМ ИМЕННО МОЖНО УПРАВЛЯТЬ В КОНСТРУКТОРЕ ????????????????
Состоянием объекта после окончания конструирования.

З.Ы. Ты неправильно понимаешь, что такое конструктор. С точки зрения ООП, задачи размещения и инициализации объекта ортогональны. Конструктор в С++ гарантирует, что нельзя получить доступ к объекту в нецелостном сотоянии. Все ограничения конструктора связаны именно с этим. Именно поэтому виртуальные методы из конструктора вызываются статически — чтобы не произвести вызов метода на недоконструированном объекте.
Гибкость при размещении дает оператор выделения памяти new. Поэтому в создающем коде принимается сразу два решения:
1. Стратегия размещения (стек/статика/одна из версий new)
2. Стратегия инициализации (один из конструкторов).
При желании эти решения можно инкапсулировать в фабрику, которая будет размещать и инициализировать объект по своему усмотрению. Но внутри метода, реализующего выбранную стратегию, уже никакого выбора не происходит.

... << RSDN@Home 1.1 beta 2 >>

Hello, s.ts!
You wrote on Thu, 16 Oct 2003 13:20:05 GMT:

s> В делфе нужно указывать вызов конструктора/деструктора базового класса,
s> но в любом месте, а можно и не указывать.

Т.е., если не указать вызов конструктора базового класса, то базовый объект останется неинициализированным?

s> Как резюме, от себя могу сказать, чтоо ИМХО конструкторы в дельфи -
s> более сильная часть чем в С++. А чего не хватает относительно С++ —
s> это краткости кода (begin, end etc.), перегрузки операторов и шаблонов.
s> Впрочем, это, видимо, общая тенденция.

А множественное наследование есть?

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

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

H_D>Так и с Дельфи — то, что вы не знаете профессионалов, которые великолепно владеют Delphi и умеют совмещать код Delphi с кодом на других ЯП (иногда — и в одном проекте) не значит, что таковых нет, а Дельфи — отстой... просто Борланд чуть лучше заботится о своих юзверях

Ага, особенно когда прекратила поддержку OWL и сказала "юзайте VCL или идите нах.".

best regards..
in hack we trust.

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

s>> В делфе нужно указывать вызов конструктора/деструктора базового класса,
s>> но в любом месте, а можно и не указывать.

S>Т.е., если не указать вызов конструктора базового класса, то базовый объект останется неинициализированным?

Инициализировано нулем или чем ты там укажешь в InitInstance — этот всегда вызывается — в некотором смысле аналог оператора new из С++.

Я помнится поначалу иногда забывал вызывать базовый конструктор

Но теперь все хорошо. Это из области перепутать в С = и == (я в своей жизни перепутал 2 раза и нашел за 2 минуты).

s>> Как резюме, от себя могу сказать, чтоо ИМХО конструкторы в дельфи -
s>> более сильная часть чем в С++. А чего не хватает относительно С++ —
s>> это краткости кода (begin, end etc.), перегрузки операторов и шаблонов.
s>> Впрочем, это, видимо, общая тенденция.

S>А множественное наследование есть?

Есть "множественное наследование" интерфейсов (кстати, COM-совместимых), что просто отражает общую тенденцию (java C# и иже с ними).

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

S>Здравствуйте, s.ts, Вы писали:
ST>>Код, приведенный выше на любом ОО языке можно написать и не показывает ЧЕМ КОНСТРУКТОР С++ ОТЛИЧАЕТСЯ ОТ ТРИГГЕРА НА СОЗДАНИЕ ОБЪЕКТА.
S>Ну, ни в одном ООЯП я не видел такого понятия, как "триггер на создание объекта". Поэтому не могу сказать,чем они отличаются.

Понятие триггер из области СУБД, но более точно отражает природу конструкторов. Конструирует объект скорее оператор new.

Кстати, триггер на создание объекта например в БД — обычное дело и почему так нельзя сказать я не понимаю.
В общем, смотрите шире: используите не "ООЯП", а ООА&D

.

А вообще-то интуитивно понятно что я имел ввиду и не нужно цепляться к словам

ST>>1.КАК В С++ ИЗ КОНСТРУКТОРВА МОЖНО УПРАВЛЯТЬ КОНСТРУИРОВАНИЕМ ОБЪЕКТА, КРОМЕ ИНИЦИАЛИЗАЦИИ ПОЛЕЙ И ВЫЗОВОВ КОНСТРУКТОРОВ БАЗОВЫХ КЛАССОВ ????????????
S>Не кричи. Ответ — никак.
ST>>2.ЧЕМ ИМЕННО МОЖНО УПРАВЛЯТЬ В КОНСТРУКТОРЕ ????????????????
S>Состоянием объекта после окончания конструирования.

S>З.Ы. Ты неправильно понимаешь, что такое конструктор. С точки зрения ООП, задачи размещения и инициализации объекта ортогональны. Конструктор в С++ гарантирует, что нельзя получить доступ к объекту в нецелостном сотоянии. Все ограничения конструктора связаны именно с этим. Именно поэтому виртуальные методы из конструктора вызываются статически — чтобы не произвести вызов метода на недоконструированном объекте.
S>Гибкость при размещении дает оператор выделения памяти new. Поэтому в создающем коде принимается сразу два решения:
S>1. Стратегия размещения (стек/статика/одна из версий new)
S>2. Стратегия инициализации (один из конструкторов).
S>При желании эти решения можно инкапсулировать в фабрику, которая будет размещать и инициализировать объект по своему усмотрению. Но внутри метода, реализующего выбранную стратегию, уже никакого выбора не происходит.

Я то, видать (см. всю ветку), все правильно понимаю.
Такие вопросы как я задал называются наводящими.
То, что ты написал должно быть хорошо известно всем пишущим на С++ и именно это я и хотел услышать от своего оппонента по имени WolfHound. Но он этого, наверное, не знает или не хочет признать, что исчерпал аргументацию.

Расширяя твой ответ,добавлю, что в дельфе обычно не нужны обертки типа фабрик классов за счет того, что конструктор может быть виртуальным и объекты всегда создаются в куче (читай в NewInstance = C++::operator new).

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

S>Здравствуйте, WolfHound, Вы писали:
S>Ну, теперь еще сделай так, чтобы я мог построить функцию, принимающую указатель на класс и вызывающую вот этот твой сreate с заданными параметрами.
S>В дельфи это будет вот так:
S>

S>type
S>  TBaseClass = class of base;
S>function CreateMyBaseDescendant(BaseClass: TBaseClass): base;
S>begin
S>  Result:= BaseClass.create(2, 4);
S>end;
S>var
S>  K: base;
S>begin
S>  K:= CreateMyBaseDescendent(some);
S>end;
S>

Нету в С++ "указателей на класс".
TClass в дельфи — это в своем роде фабрика классов, но встроенная в компилятор. На С++ делается все то же самое, но с дополнительными усилиями.

Для удовлетворения же твоего желания на С++ нужно передавать указатель на фабрику класса. RTTI (читай фабрики) там реализуются при помощи шаблонов, ибо другого универсального пути (кроме как встраивание в компилятор, что сделал Борланд) ИМХО нет.

Hello, s.ts!
You wrote on Thu, 16 Oct 2003 14:11:55 GMT:

s>>> В делфе нужно указывать вызов конструктора/деструктора базового
s>>> класса, но в любом месте, а можно и не указывать.

S>> Т.е., если не указать вызов конструктора базового класса, то базовый
S>> объект останется неинициализированным?

s> Инициализировано нулем или чем ты там укажешь в InitInstance — этот
s> всегда вызывается — в некотором смысле аналог оператора new из С++.

В некотором смысле, это аналог конструктора в С++

Оператор new занимается выделением памяти под объекты и вызовом конструкторов, а не их собственно созданием объектов.

Кстати, вот тебе и причина, по которой С++'ный конструктор сложного объекта будет быстрее — там дефолт инициализация базовых объектов и мемберов не обязательна, можно сразу вызвать нужный конструктор с параметром.

s> Я помнится поначалу иногда забывал вызывать базовый конструктор

Но
s> теперь все хорошо. Это из области перепутать в С = и == (я в своей жизни
s> перепутал 2 раза и нашел за 2 минуты).

Значит, просто мало программировал на С

S>> А множественное наследование есть?

s> Есть "множественное наследование" интерфейсов (кстати, COM-совместимых),
s> что просто отражает общую тенденцию (java C# и иже с ними).

Это не просто тенденция, а следствие наличия общего для всех объектов предка.

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

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

S>Hello, s.ts!
S>You wrote on Thu, 16 Oct 2003 14:11:55 GMT:

s>>>> В делфе нужно указывать вызов конструктора/деструктора базового
s>>>> класса, но в любом месте, а можно и не указывать.

S>>> Т.е., если не указать вызов конструктора базового класса, то базовый
S>>> объект останется неинициализированным?

s>> Инициализировано нулем или чем ты там укажешь в InitInstance — этот
s>> всегда вызывается — в некотором смысле аналог оператора new из С++.

S>В некотором смысле, это аналог конструктора в С++

Оператор new занимается выделением памяти под объекты и вызовом конструкторов, а не их собственно созданием объектов.

Согласен

. Моя аналогия не правильна.

S>Кстати, вот тебе и причина, по которой С++'ный конструктор сложного объекта будет быстрее — там дефолт инициализация базовых объектов и мемберов не обязательна, можно сразу вызвать нужный конструктор с параметром.

Как раз для дефолтного поведения хотелось бы чтобы все инициализировалось нулем, чтобы меньше писать и (внимание) не думать что ты получишь в деструкторе если в конструкторе возникнет исключение. А вот это поведение по умолчанию в дельфе можно менять. В общем, сомнительная плата за быстродействие.

s>> Я помнится поначалу иногда забывал вызывать базовый конструктор

Но
s>> теперь все хорошо. Это из области перепутать в С = и == (я в своей жизни
s>> перепутал 2 раза и нашел за 2 минуты).

S>Значит, просто мало программировал на С

Померяемся, у кого длиннее ?

Далее серьезно:
М.б. я этих ошибок и сделал много, но на этапе тренировки — когда только изучал С++ — это было давно и к моменту начала реальной работы уже были изжиты. М.б. так ? Но я действительно не помню чтобы это доставляло мне хоть какие-то неудобства.

S>>> А множественное наследование есть?

s>> Есть "множественное наследование" интерфейсов (кстати, COM-совместимых),
s>> что просто отражает общую тенденцию (java C# и иже с ними).

S>Это не просто тенденция, а следствие наличия общего для всех объектов предка.

В С++ ни кто не мешает делать множественное наследование от классов с общим предком (просто он должен быть виртуальным базовым классом). Так что следствия тут нет.

Интерфейсы в дельфи скорее частный случай множественного наследования в C++.

Hello, s.ts!
You wrote on Thu, 16 Oct 2003 15:14:38 GMT:

S>> Кстати, вот тебе и причина, по которой С++'ный конструктор сложного
S>> объекта будет быстрее — там дефолт инициализация базовых объектов и
S>> мемберов не обязательна, можно сразу вызвать нужный конструктор с
S>> параметром.

s> Как раз для дефолтного поведения хотелось бы чтобы все
s> инициализировалось нулем, чтобы меньше писать и (внимание) не думать что
s> ты получишь в деструкторе если в конструкторе возникнет исключение.

А в случае возникновения исключения в конструкторе деструктор просто не вызывается, только и всего.

s> А вот это поведение по умолчанию в дельфе можно менять. В общем,
s> сомнительная плата за быстродействие.

Это не плата за быстродействие, а желание Страуструпа отучить программистов от процедурного стиля программирования

s>>> Я помнится поначалу иногда забывал вызывать базовый конструктор

Но
s>>> теперь все хорошо. Это из области перепутать в С = и == (я в своей
s>>> жизни перепутал 2 раза и нашел за 2 минуты).

S>> Значит, просто мало программировал на С

s> Померяемся, у кого длиннее ?

Зачем? Мне и так понятно, что ты либо приврал, либо гений внимательности (не верю

), либо действительно мало программировал на С/С++.

s> Далее серьезно:
s> М.б. я этих ошибок и сделал много, но на этапе тренировки — когда только
s> изучал С++ — это было давно и к моменту начала реальной работы уже были
s> изжиты. М.б. так ? Но я действительно не помню чтобы это доставляло мне
s> хоть какие-то неудобства.

Ну, отсутствие неудобств — это одно, 2 ошибки с = и == за всю практику программирования — совсем другое

s>>> Есть "множественное наследование" интерфейсов (кстати,
s>>> COM-совместимых), что просто отражает общую тенденцию (java C# и иже с
s>>> ними).

S>> Это не просто тенденция, а следствие наличия общего для всех объектов
S>> предка.

s> В С++ ни кто не мешает делать множественное наследование от классов с
s> общим предком (просто он должен быть виртуальным базовым классом).

Во-первых, не должен, а может быть виртуальным базовым классом. Во-вторых, виртуальное aka "бриллиантовое" множественное наследование реализуется на порядок сложнее обычного, да и прикладному программисту с ним тоже не просто обращаться. А нужно оно очень редко.

s> Так что следствия тут нет.

Если разрешить любое множественное наследование от классов с данными (не-интерфейсов) в языках типа C#, то любое наследование в них придется делать виртуальным. Проще оказалось вообще забить на множественное наследование

.

s> Интерфейсы в дельфи скорее частный случай множественного наследования в C++.
Да.

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

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

S>Hello, s.ts!
S>You wrote on Thu, 16 Oct 2003 15:14:38 GMT:

S>>> Кстати, вот тебе и причина, по которой С++'ный конструктор сложного
S>>> объекта будет быстрее — там дефолт инициализация базовых объектов и
S>>> мемберов не обязательна, можно сразу вызвать нужный конструктор с
S>>> параметром.

s>> Как раз для дефолтного поведения хотелось бы чтобы все
s>> инициализировалось нулем, чтобы меньше писать и (внимание) не думать что
s>> ты получишь в деструкторе если в конструкторе возникнет исключение.

S>А в случае возникновения исключения в конструкторе деструктор просто не вызывается, только и всего.

Память то надо все равно освободить

s>> А вот это поведение по умолчанию в дельфе можно менять. В общем,
s>> сомнительная плата за быстродействие.

S>Это не плата за быстродействие, а желание Страуструпа отучить программистов от процедурного стиля программирования

Какая тут связь ?

S>Зачем? Мне и так понятно, что ты либо приврал, либо гений внимательности (не верю

), либо действительно мало программировал на С/С++.

Эту несодержательную тему мы оставим.

s>> Далее серьезно:
s>> М.б. я этих ошибок и сделал много, но на этапе тренировки — когда только
s>> изучал С++ — это было давно и к моменту начала реальной работы уже были
s>> изжиты. М.б. так ? Но я действительно не помню чтобы это доставляло мне
s>> хоть какие-то неудобства.

S>Ну, отсутствие неудобств — это одно, 2 ошибки с = и == за всю практику программирования — совсем другое

Эту несодержательную тему мы оставим. Просто хотелось предвосхитить возгласы о том, как сложно написать лишнюю строчку.

s>>>> Есть "множественное наследование" интерфейсов (кстати,
s>>>> COM-совместимых), что просто отражает общую тенденцию (java C# и иже с
s>>>> ними).

S>>> Это не просто тенденция, а следствие наличия общего для всех объектов
S>>> предка.

s>> В С++ ни кто не мешает делать множественное наследование от классов с
s>> общим предком (просто он должен быть виртуальным базовым классом).

S>Во-первых, не должен, а может быть виртуальным базовым классом. Во-вторых, виртуальное aka "бриллиантовое" множественное наследование реализуется на порядок сложнее обычного, да и прикладному программисту с ним тоже не просто обращаться. А нужно оно очень редко.

s>> Так что следствия тут нет.

S>Если разрешить любое множественное наследование от классов с данными (не-интерфейсов) в языках типа C#, то любое наследование в них придется делать виртуальным. Проще оказалось вообще забить на множественное наследование

.

То, что сложнее — это точно. А все виртульным делать не надо. Достаточно только от базового aka Object aka TObject aka CObject чтобы RTTI было, для чего все и затевалось.

Здравствуйте, s.ts, Вы писали:
ST>Нету в С++ "указателей на класс".
ST>TClass в дельфи — это в своем роде фабрика классов, но встроенная в компилятор. На С++ делается все то же самое, но с дополнительными усилиями.
Вот как раз это-то я очень неплохо знаю. Мне и интересно, какие дополнительные усилия надо предпринять. Wolfhound написал :

О уже почти дельфя. Вернее логически один в один.

А я ему намекаю, что нифига это не один в один. Пусть покажет один в один.
S>Для удовлетворения же твоего желания на С++ нужно передавать указатель на фабрику класса. RTTI (читай фабрики) там реализуются при помощи шаблонов, ибо другого универсального пути (кроме как встраивание в компилятор, что сделал Борланд) ИМХО нет.

... << RSDN@Home 1.1 beta 2 >>

Здравствуйте, s.ts, Вы писали:
ST>Понятие триггер из области СУБД,
да
ST>но более точно отражает природу конструкторов.
нет
ST>Конструирует объект скорее оператор new.
Ну конечно же нет
ST>Кстати, триггер на создание объекта например в БД — обычное дело и почему так нельзя сказать я не понимаю.
В БД НЕТ объектов. Триггер на создание записи — совсем другая фишка.
ST>В общем, смотрите шире: используите не "ООЯП", а ООА&D

.
Да я с удовольствием. В ООА&D тоже нету триггеров.
ST>А вообще-то интуитивно понятно что я имел ввиду и не нужно цепляться к словам

Ок, не будем
ST>Я то, видать (см. всю ветку), все правильно понимаю.
Смотрю. Не уверен

ST>Расширяя твой ответ,добавлю, что в дельфе обычно не нужны обертки типа фабрик классов за счет того, что конструктор может быть виртуальным и объекты всегда создаются в куче (читай в NewInstance = C++::operator new).
Я в курсе. Это как раз очень плохо. Фактически, отсутствие способа размещать объекты на стеке мешает повысить эффективность операция распределения памяти для объектов со scope lifetime, т.е. порядок удаления которых в точности обратен порядку их создания. В Дельфи вообще другое понимание термина "конструктор". Половина войн с ++ программерами именно из-за этого. В плюсах конструкторы строже. Нужно понимать, что в плюсах создание объекта — двухстадийное, а в Дельфи — четырехстадийное (NewInstance/InitInstance/Create/AfterConstruction). В плюсах InitInstance отсутствует, поэтому нельзя трактовать конструктор, как обычную функцию. А в Дельфи можно вызывать конструктор сколько угодно раз на уже готовом объекте.
Зато дельфи реализует паттерн "абстрактная фабрика" натуральным образом. Мне до сих пор интересно, можно ли в точности воспроизвести семантику Delphi средствами плюсов, не влезая в компилятор.

... << RSDN@Home 1.1 beta 2 >>

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

ST>В делфе нужно указывать вызов конструктора/деструктора базового класса, но в любом месте, а можно и не указывать.
Как устроен конструктор в дельфе и как это можно эмулировать на С++ я уже писал.

ST>Прибавки в скорости перечисленное выше, конечно же не дает никакой

Ага... как ты думаешь что быстрее создать объект с заданным состоянием или создать объект с состоянием по умолчанию и изменить его состояние потом?
К томуже в аналогичном примере на дельфе будет на два обращения к менеджеру память больше, а если учесть что обычно класса содержит несколько классов челенов то...
И я еще не начал про дельфийские контейнеры расказывать... и что они есть против STL которую на дельфе не возможно реализовать.

ST>Как резюме, от себя могу сказать, чтоо ИМХО конструкторы в дельфи — более сильная часть чем в С++.
Как можно получить тотже эффект на С++ я уже говорил.
ST>А чего не хватает относительно С++ — это краткости кода (begin, end etc.),
Фигня
ST>перегрузки операторов и шаблонов.
О а вот это на столько круто что даже не все С++ники представляют.

... << RSDN@Home 1.1 beta 2 >>

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

ST>Память то надо все равно освободить

А в С++ ни кто delete не пишет.

struct some_t{};
struct some_else_t
{
    std::auto_ptr<some_t> some;
    some_else_t()
        :some(new some_t)
    {
        throw 1;
    }
};

Утечек не будет.

... << RSDN@Home 1.1 beta 2 >>

Я знаю одного уже несколько лет. Дык вот некоторое время назад он решил что пора переходить на С++ и собирается сделать это при первой возможности. Интересно почему?

... << RSDN@Home 1.1 beta 2 >>

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

S>А я ему намекаю, что нифига это не один в один. Пусть покажет один в один.
Вот я и думаю как это сделать красиво.
Как вариант можно так

/*****************************************************/
template<class class_t>
struct get_delphi_ctor
{
    class_t* operator()()
    {
        return class_t::create();
    }
    template<class param1_t>
    class_t* operator()(param1_t param1)
    {
        return class_t::create(param1);
    }
    template<class param1_t, class param2_t>
    class_t* operator()(param1_t param1, param2_t param2)
    {
        return class_t::create(param1, param2);
    }
    //Продолжить по вкусу
};
/*****************************************************/

Остальное как тут (только надо исправить virtual delphi_dtor())

base* CreateMyBaseDescendant(boost::function<base*(float,float)> fn)
{
    return fn(2, 4);
}
int main()
{
    base* ptr=CreateMyBaseDescendant(get_delphi_ctor<some>());
    ptr->destroy();
    return 0;
}

Хотя boost::function в данном случае как из пушки по воробьям ну да ладно.

... << RSDN@Home 1.1 beta 2 >>

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

WH>>>В дельфе нет конструкторов в том виде в котором они есть в С++. В дельфе это фабричная функция
FWP>>Если вы думаете, что программирование заканчивается на Windows и OLE, то вы несколько заблуждаетесь.
WH>

Ты вобще о чем?
Это я о фабричной функции.

WH>>>Ну в С++ оно теже есть. Конечно список пропертей из паблишед не получить да и в С++ пиблишед нету но для работы вполне достаточно.
FWP>>Принимается! Замечательный ответ. Только когда вам отвечают таким же образом реакция почему-то другая

WH>И для чего кроме ГУИ это полезно? Вот толко не надо про сериализацию я на С++ и круче могу.

FWP>>Потом стало лениво писать на С — придумали С++
FWP>>Потом стало лениво писать на С++ — придумали ... Что придумали?
WH>.NET
А вот и нет. Сначала они придумали VB и Delphi. Потом Java. Потом почитали вот такие форумы и решили сделать .NET

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

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

ST>>В делфе нужно указывать вызов конструктора/деструктора базового класса, но в любом месте, а можно и не указывать.
WH>Как устроен конструктор в дельфе и как это можно эмулировать на С++ я уже писал.
Это все было не то

ST>>Прибавки в скорости перечисленное выше, конечно же не дает никакой

WH>Ага... как ты думаешь что быстрее создать объект с заданным состоянием или создать объект с состоянием по умолчанию и изменить его состояние потом?

Это поведение по умолчанию, которое можно изменить.

WH>К томуже в аналогичном примере на дельфе будет на два обращения к менеджеру память больше, а если учесть что обычно класса содержит несколько классов челенов то...

Почему ?

WH>И я еще не начал про дельфийские контейнеры расказывать... и что они есть против STL которую на дельфе не возможно реализовать.

Чего-то я не припомню языка кроме С++ на котором можно STL реализовать.

ST>>Как резюме, от себя могу сказать, чтоо ИМХО конструкторы в дельфи — более сильная часть чем в С++.
WH>Как можно получить тотже эффект на С++ я уже говорил.
ST>>А чего не хватает относительно С++ — это краткости кода (begin, end etc.),
WH>Фигня
ST>>перегрузки операторов и шаблонов.
WH>О а вот это на столько круто что даже не все С++ники представляют.

В смысле ? Если не представляют, то ....

зачем они делают ЭТО (в смысле, пишут на С++)

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

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

ST>>Память то надо все равно освободить

WH>А в С++ ни кто delete не пишет.
WH>

WH>struct some_t{};
WH>struct some_else_t
WH>{
WH>    std::auto_ptr<some_t> some;
WH>    some_else_t()
WH>        :some(new some_t)
WH>    {
WH>        throw 1;
WH>    }
WH>};
WH>

WH>Утечек не будет.

Так ведь автоуказатель-неавтоуказатель все равно вызывается деструктор (или что другое) чтобы освободить ресурсы. А ты даже не знаешь выделены ли они.

М.б. будет понятно из кода:

MyClass *c=NULL; 
try
{
  c = new MyClass();
} 
catch(...)
{
  delete c;
}

Если переменную с не инициализировать, то будет AV на вызове delete.

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

S>Здравствуйте, s.ts, Вы писали:
ST>>Понятие триггер из области СУБД,
S>да
ST>>но более точно отражает природу конструкторов.
S>нет
ST>>Конструирует объект скорее оператор new.
S>Ну конечно же нет

^- это мы оставим. Просто в дельфе и в С++ конструкторами называются немного разные вещи.

ST>>Кстати, триггер на создание объекта например в БД — обычное дело и почему так нельзя сказать я не понимаю.
S>В БД НЕТ объектов. Триггер на создание записи — совсем другая фишка.
Есть. Еще и какие — с полиморфизмом и прочими атрибутами ООП (см. для примера Oracle Types : http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96540/statements_82a.htm).

ST>>Я то, видать (см. всю ветку), все правильно понимаю.
S>Смотрю. Не уверен

Предлагаю воздержаться от взаимных оценок.
ST>>Расширяя твой ответ,добавлю, что в дельфе обычно не нужны обертки типа фабрик классов за счет того, что конструктор может быть виртуальным и объекты всегда создаются в куче (читай в NewInstance = C++::operator new).
S>Я в курсе. Это как раз очень плохо. Фактически, отсутствие способа размещать объекты на стеке мешает повысить эффективность операция распределения памяти для объектов со scope lifetime, т.е. порядок удаления которых в точности обратен порядку их создания. В Дельфи вообще другое понимание термина "конструктор". Половина войн с ++ программерами именно из-за этого. В плюсах конструкторы строже. Нужно понимать, что в плюсах создание объекта — двухстадийное, а в Дельфи — четырехстадийное (NewInstance/InitInstance/Create/AfterConstruction). В плюсах InitInstance отсутствует, поэтому нельзя трактовать конструктор, как обычную функцию. А в Дельфи можно вызывать конструктор сколько угодно раз на уже готовом объекте.

Конструктор С++ == InitInstance. В С++ отсутствует конструктор в том смысле, который вкладывается в дельфи, но его можно создать.

S>Зато дельфи реализует паттерн "абстрактная фабрика" натуральным образом. Мне до сих пор интересно, можно ли в точности воспроизвести семантику Delphi средствами плюсов, не влезая в компилятор.

Можно. Благо есть шаблоны и макросы. Но дополнительная работа

Да и не нужно это. Просто разные стили написания программ на С++ и дельфи. А стиль порождается возможностями языка. Например, в дельфе очень широко используется 'паттерн "абстрактная фабрика"'

Hello, s.ts!
You wrote on Thu, 16 Oct 2003 15:59:30 GMT:

s>>> Как раз для дефолтного поведения хотелось бы чтобы все
s>>> инициализировалось нулем, чтобы меньше писать и (внимание) не думать
s>>> что ты получишь в деструкторе если в конструкторе возникнет исключение.

S>> А в случае возникновения исключения в конструкторе деструктор просто не
S>> вызывается, только и всего.

s> Память то надо все равно освободить

Ага. Если не делать ошибок, она будет освобождена — деструктор для базового класса вызовется, деструкторы для членов вызовутся.

s>>> А вот это поведение по умолчанию в дельфе можно менять. В общем,
s>>> сомнительная плата за быстродействие.

S>> Это не плата за быстродействие, а желание Страуструпа отучить
S>> программистов от процедурного стиля программирования

s> Какая тут связь ?

Ну, например, использование более одного "голого" указателя как членов класса сильно затрудняет написание exception-safe кода, что побуждает использовать разнообразные смарт-пойнтеры. Каждый ресурс заворачивается в отдельный класс, утечек нет. Да и finally в С++ отсутствует из тех же соображений.

S>> Если разрешить любое множественное наследование от классов с
S>> данными (не-интерфейсов) в языках типа C#, то любое наследование
S>> в них придется делать виртуальным. Проще оказалось вообще забить на
S>> множественное наследование

.

s> То, что сложнее — это точно. А все виртульным делать не надо. Достаточно
s> только от базового aka Object aka TObject aka CObject чтобы RTTI было,
s> для чего все и затевалось.

Вот именно — у каждого объекта будет виртуальный базовый класс — который в отсутствие множественного наследования был бы просто базовым. Дороговато.

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

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

S>Ага. Если не делать ошибок, она будет освобождена — деструктор для базового класса вызовется, деструкторы для членов вызовутся.

Ну а как в деструкторе понять, что ресурс не бы выделен ?

Как вариант :

class My
{
  Handle h[100];
  My()
  {
    for(int i=0; i<100; i++)
    {
      h[i] = 0;
      h[i] = CreateHandle();
    }
  };
  ~My()
  {
    for(int i=0; i<100; i++)
    {
      if(handle!=0)
        ReleaseHandle(h);
    }
  };
}

Где начальную инициализацию лучше делать автоматически по умолчанию. И не говори, что там можно использовать Vector или любой другой класс вместо голого массива. Ведь может быть еще хуже — все h оазных типов.

s>>>> А вот это поведение по умолчанию в дельфе можно менять. В общем,
s>>>> сомнительная плата за быстродействие.

S>>> Это не плата за быстродействие, а желание Страуструпа отучить
S>>> программистов от процедурного стиля программирования

s>> Какая тут связь ?

S>Ну, например, использование более одного "голого" указателя как членов класса сильно затрудняет написание exception-safe кода, что побуждает использовать разнообразные смарт-пойнтеры. Каждый ресурс заворачивается в отдельный класс, утечек нет. Да и finally в С++ отсутствует из тех же соображений.

Это оставим на совести Страуструпа.

S>>> Если разрешить любое множественное наследование от классов с
S>>> данными (не-интерфейсов) в языках типа C#, то любое наследование
S>>> в них придется делать виртуальным. Проще оказалось вообще забить на
S>>> множественное наследование

.

s>> То, что сложнее — это точно. А все виртульным делать не надо. Достаточно
s>> только от базового aka Object aka TObject aka CObject чтобы RTTI было,
s>> для чего все и затевалось.

S>Вот именно — у каждого объекта будет виртуальный базовый класс — который в отсутствие множественного наследования был бы просто базовым. Дороговато.

Но не вся иерархия наследования будет виртуальной, а только на самом верхнем уровне (у корня)
Насчет дороговато :
1 лишний указатель в VMT ???

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

WH>>Как устроен конструктор в дельфе и как это можно эмулировать на С++ я уже писал.
ST>Это все было не то

Что не то? Ты хочешь сказать что в дельфе конструктор устроен иначе чем я показал?

WH>>К томуже в аналогичном примере на дельфе будет на два обращения к менеджеру память больше, а если учесть что обычно класса содержит несколько классов челенов то...
ST>Почему ?
А там все контейнеры это классы, а все классы создаются в хипе...

WH>>И я еще не начал про дельфийские контейнеры расказывать... и что они есть против STL которую на дельфе не возможно реализовать.
ST>Чего-то я не припомню языка кроме С++ на котором можно STL реализовать.
Ну мне попадались перци которые утверждали что на делфе они это могут сделать легко

WH>>О а вот это на столько круто что даже не все С++ники представляют.
ST>В смысле ? Если не представляют, то ....

зачем они делают ЭТО (в смысле, пишут на С++)
Есть такое понятие С с классами дак вот большинство пишет на С с классами хотя считают что пишут на С++

... << RSDN@Home 1.1 beta 2 >>

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

ST>Так ведь автоуказатель-неавтоуказатель все равно вызывается деструктор (или что другое) чтобы освободить ресурсы.
Деструктор автоуказателя.
ST>А ты даже не знаешь выделены ли они.
Знаю выделены иначе автоуказатель не будет создан.

ST>М.б. будет понятно из кода:
хъ
ST>Если переменную с не инициализировать, то будет AV на вызове delete.
С автоуказателями такой проблемы нет ибо они имеют конструктор по умолчанию который инициализирует внутренный указатель нулем.

Вобще грамотная С++ программа это куча шаблонных кирпичиков каждый из которых выполняет ту и только ту маленькую часть работы кторую должен. std::auto_ptr реализует смартпоинтер со стратегией эксклюзивного владения, boost::shared_ptr раздельное владение(реализовано через внешний подсчет ссылок)...
Из них собирают кирпичи по крупнее которые надеятся на то что заданные свойства маленьких кирпичиков в точности соблюдены. И так далие.

ИМХО в идеальной программе нет двух кусков кода которые далают одно и тоже. С++ программы очень близки к идеальным. Гораздо ближе чем дельфийские ибо например встретить delete в программе на С++ (а не С с классами) кроме как в нутри смартпоинтера нельзя. В тоже время на дельфе free обычное дело. И тд и тп.

... << RSDN@Home 1.1 beta 2 >>

Hello, s.ts!
You wrote on Fri, 17 Oct 2003 08:12:20 GMT:

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

S>> Ага. Если не делать ошибок, она будет освобождена — деструктор для
S>> базового класса вызовется, деструкторы для членов вызовутся.

s> Ну а как в деструкторе понять, что ресурс не бы выделен ?

Еще раз — деструкторы для недоконструированных объектов не вызываются.

s> Как вариант :

s>

 s> class My
 s> {
 s>   Handle h[100];
 s>   My()
 s>   {
 s>     for(int i=0; i<100; i++)
 s>     {
 s>       h[i] = 0;
 s>       h[i] = CreateHandle();
 s>     }
 s>   };
 s>   ~My()
 s>   {
 s>     for(int i=0; i<100; i++)
 s>     {
 s>       if(handle!=0)
 s>         ReleaseHandle(h);
 s>     }
 s>   };
 s> }
 s>

Куда лучше будет так:

class My
{
class sHandle
{
Handle _h;
sHandle()
{ _h = CreateHandle(); }
~sHandle()
{ ReleaseHandle(_h); }
};
sHandle _h[100];
};

И никаких проблем с исключениями в CreateHandle.

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

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

WH>Что не то? Ты хочешь сказать что в дельфе конструктор устроен иначе чем я показал?
Все гораздо проще и примерно так:
delphi.NewInstance = C++::operator new, delphi.InitInstance = C++::constructor,
delphi.constructor = фабричная функция в C++.

WH>>>К томуже в аналогичном примере на дельфе будет на два обращения к менеджеру память больше, а если учесть что обычно класса содержит несколько классов челенов то...
ST>>Почему ?
WH>А там все контейнеры это классы, а все классы создаются в хипе...
А есть языки где все суть есть класс

и дельфя ближе к ним.

WH>>>И я еще не начал про дельфийские контейнеры расказывать... и что они есть против STL которую на дельфе не возможно реализовать.
ST>>Чего-то я не припомню языка кроме С++ на котором можно STL реализовать.
WH>Ну мне попадались перци которые утверждали что на делфе они это могут сделать легко

WH>>>О а вот это на столько круто что даже не все С++ники представляют.
ST>>В смысле ? Если не представляют, то ....

зачем они делают ЭТО (в смысле, пишут на С++)
WH>Есть такое понятие С с классами дак вот большинство пишет на С с классами хотя считают что пишут на С++

> С++ программы очень близки к идеальным
WH, камрад, расскажи мне пожалуйста, что такое идеальная программа?

А вообше, народ, кончайте на эту тему копья ломать (я про автопойнтеры). В этой ветке ведь поначалу обсуждалось, "как же конструктор C++ конструирует объект и какие преимущества по сравнению с дельфи это дает". О наличии и отсутствии шаблонов речь не шла (и не могла идти — смысла нет, это однозначно недостаток Delphi). А ваша полемика упорно сбивается в этом направлении.

WH, представь себе, что шаблонов НЕТУ

Slicer

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

S>Hello, s.ts!
S>You wrote on Fri, 17 Oct 2003 08:12:20 GMT:

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

S>Куда лучше будет так:

S>class My
S>{
S> class sHandle
S> {
S> Handle _h;
S> sHandle()
S> { _h = CreateHandle(); }
S> ~sHandle()
S> { ReleaseHandle(_h); }
S> };
S> sHandle _h[100];
S>};

S>И никаких проблем с исключениями в CreateHandle.

Согласен, но одно большое "НО":
Изначально разговор был о производительности. А тут мы экономим операцию записи в память за счет операции вызова функции (и не дай бог виртуальной — если через фабрику создавать).
Да, и не говорите мне пожалуйста об инлайн-расширении.

Hello, s.ts!
You wrote on Fri, 17 Oct 2003 08:55:45 GMT:

s> Согласен, но одно большое "НО":
s> Изначально разговор был о производительности.

Да, но перестал быть разговором о производительности, как только речь зашла об исключениях в конструкторах

Потому что исключения вообще штука достаточно медленная. Разговор пошел о том, что в дельфи мы делаем дефолтную инициализацию всегда, а в С++ — только когда надо (компилятор все равно какие-то невидимые флаги выставляет, чтобы обеспечить правильную работу с недоконструированными объектами).

s> А тут мы экономим операцию
s> записи в память за счет операции вызова функции (и не дай бог
s> виртуальной — если через фабрику создавать).

Нифига. Операция записи в память здесь лишняя — она ничего не дает. Если хочется делать закат солнца вручную — изволь обложить свой цикл try/catch и освобождать ресурсы в catch.

s> Да, и не говорите мне пожалуйста об инлайн-расширении.

Почему? Очень полезная фича.

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

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

...

WH>Вобще грамотная С++ программа это куча шаблонных кирпичиков каждый из которых выполняет ту и только ту маленькую часть работы кторую должен. std::auto_ptr реализует смартпоинтер со стратегией эксклюзивного владения, boost::shared_ptr раздельное владение(реализовано через внешний подсчет ссылок)...
WH>Из них собирают кирпичи по крупнее которые надеятся на то что заданные свойства маленьких кирпичиков в точности соблюдены. И так далие.

WH>ИМХО в идеальной программе нет двух кусков кода которые далают одно и тоже. С++ программы очень близки к идеальным. Гораздо ближе чем дельфийские ибо например встретить delete в программе на С++ (а не С с классами) кроме как в нутри смартпоинтера нельзя. В тоже время на дельфе free обычное дело. И тд и тп.

Ну, скажем, на Delphi вполне можно так писать программы, по крайней мере для своих объектов никогда не вызывать деструктор вручную. И именно с использованием смартпоинтеров. (Я так и стараюсь делать).

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

...

WH>>>>О а вот это на столько круто что даже не все С++ники представляют.
ST>>>В смысле ? Если не представляют, то ....

зачем они делают ЭТО (в смысле, пишут на С++)
WH>>Есть такое понятие С с классами дак вот большинство пишет на С с классами хотя считают что пишут на С++

ST>

Если я правильно ошибаюсь, в С с классами — сами классы тоже были объектами. Жаль что в С++ они не попали.

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

WH>>А там все контейнеры это классы, а все классы создаются в хипе...
ST>А есть языки где все суть есть класс

и дельфя ближе к ним.

И какое это имеет отношение к обращениям к хипу которых могло и не быть?

Здравствуйте, Slicer [Wirkwood], Вы писали:

>> С++ программы очень близки к идеальным
SW>WH, камрад, расскажи мне пожалуйста, что такое идеальная программа?

Ды эта... зачем поскипал?

SW>А вообше, народ, кончайте на эту тему копья ломать (я про автопойнтеры). В этой ветке ведь поначалу обсуждалось, "как же конструктор C++ конструирует объект и какие преимущества по сравнению с дельфи это дает". О наличии и отсутствии шаблонов речь не шла (и не могла идти — смысла нет, это однозначно недостаток Delphi). А ваша полемика упорно сбивается в этом направлении.
Ну считайте что мой поинт в том что в С++ за всем следит компилятор, а в дельфе ручками...

SW>WH, представь себе, что шаблонов НЕТУ

Ага и метаклассов в С++ нету. И о чем тогда спорить?

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

ST>Согласен, но одно большое "НО":
ST>Изначально разговор был о производительности. А тут мы экономим операцию записи в память за счет операции вызова функции (и не дай бог виртуальной — если через фабрику создавать).
ST>Да, и не говорите мне пожалуйста об инлайн-расширении.
Почему? В данном случае все очень хорошо инлайнится.

WH>И о чем тогда спорить?

Ну так и я не понимаю — чего вам всем времени не жалко?
Поспорьте лучше о сравнительных характеристиках C++ и C# — хотя бы актуально

Slicer

P.S. Это тактический маневр был — перессорить Цников

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

M>Ну, скажем, на Delphi вполне можно так писать программы, по крайней мере для своих объектов никогда не вызывать деструктор вручную. И именно с использованием смартпоинтеров. (Я так и стараюсь делать).
А какой ценой? Таскать объекты исключительно через интерфейсы? Создавать еще один объект смартпоинтер +1 обращение к хипу и работа через виртуальные функции в место стека и инлайна в С++? А как это все выглядит...

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

M>Если я правильно ошибаюсь, в С с классами — сами классы тоже были объектами. Жаль что в С++ они не попали.
Имелся в виду стиль программирования "С с классами" те программа фактически написана на С но с использованием классов.
Это далеко не тоже самой что программа на С++. На С++ получается в несколько раз короче и надежней. Просто к сожалению не все умеют.

Здравствуйте, Slicer [Wirkwood], Вы писали:

SW>Ну так и я не понимаю — чего вам всем времени не жалко?
Ну развлекаться тоже иногда надо.
SW>Поспорьте лучше о сравнительных характеристиках C++ и C# — хотя бы актуально

Где ты был летом? Тут такая война шла...

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

M>>Ну, скажем, на Delphi вполне можно так писать программы, по крайней мере для своих объектов никогда не вызывать деструктор вручную. И именно с использованием смартпоинтеров. (Я так и стараюсь делать).

WH>А какой ценой? Таскать объекты исключительно через интерфейсы? Создавать еще один объект смартпоинтер +1 обращение к хипу и работа через виртуальные функции в место стека и инлайна в С++? А как это все выглядит...

Через интерфейсы.

Во-первых, это очень удобно для небольших и часто используемых (локально) объектов.

Во-вторых, это заставляет тщательнЕе задумываться о времени жизни сложных/составных объектов — проблема циклических ссылок, и как следствие зачастую пересматривать общий каркас программы. А так же упрощает возможность переноса программ на другие (

) языки, тот же Delphi.Net.

Во-третьих, с точки зрения самого программирования, оперирование интерфейсами вместо оперирования реализациями — гибче, мощнее и в конечном счёте правильнее. Это подтверждают и последние (и даже не очень последние) тенценции в язаках — типа Java, C# (да и .Net в целом).

Кроме того, очень многи паттерны программирования хорошо реализуются только с помощью абстрактных классов (С++) и интерфейсов. В частности, в Delphi очень, имхо, удачно сделана возможность реализации интерфейса через агрегатирование.

Собственно говоря, большое имхо, возможность управления жизнью объектов через интерфейсы — это побочный, а не основной эффект их использования.

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

M>Во-первых, это очень удобно для небольших и часто используемых (локально) объектов.
Нет для этого очень удобно складывать их на стек.

M>Во-вторых, это заставляет тщательнЕе задумываться о времени жизни сложных/составных объектов — проблема циклических ссылок, и как следствие зачастую пересматривать общий каркас программы.
В С++ таже фигня

M>А так же упрощает возможность переноса программ на другие (

) языки, тот же Delphi.Net.
Спорноное преймущество.

M>Во-третьих, с точки зрения самого программирования, оперирование интерфейсами вместо оперирования реализациями — гибче, мощнее и в конечном счёте правильнее. Это подтверждают и последние (и даже не очень последние) тенценции в язаках — типа Java, C# (да и .Net в целом).
Это мне обьяснять не надо. Но сам подумай Зачем мне на каждый чих заводить интерфейс если можно положить в стек и не париться.

M>Кроме того, очень многи паттерны программирования хорошо реализуются только с помощью абстрактных классов (С++) и интерфейсов. В частности, в Delphi очень, имхо, удачно сделана возможность реализации интерфейса через агрегатирование.
В С++ подключение реализации сделано куда круче. Особенно если применить фантазию и шаблоны.

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

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

S>Hello, s.ts!
S>You wrote on Fri, 17 Oct 2003 08:55:45 GMT:

s>> Согласен, но одно большое "НО":
s>> Изначально разговор был о производительности.

S>Разговор пошел о том, что в дельфи мы делаем дефолтную инициализацию всегда, а в С++ — только когда надо (компилятор все равно какие-то невидимые флаги выставляет, чтобы обеспечить правильную работу с недоконструированными объектами).

Но в делфи это поведение можно менять. ИМХО начальная инициализация обеспечивает большую безопасность, а в дельфе она по умолчанию включена. Это-то мне и нравится. А когда начинаем борьбу за производительность, то можно и отключить. Впрочем, про начальную инициализацию, кажется, несколько страниц написано в thinking in java.

На счет невидимых флагов — это что-то не то. Тут надо разбираться что в С++ происходит. (нужно поднять страуструпа)

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

WH>Где ты был летом? Тут такая война шла...

"Раньше была одна овсянка." Иными словами, военные сборы

Slicer

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

WH>Это мне обьяснять не надо. Но сам подумай Зачем мне на каждый чих заводить интерфейс если можно положить в стек и не париться.

Не нужно создавать дополнительный интерфейс на каждый чих. Можно сделать 1 интерфейс и 1 класс (смарт-пойнтер) в котором этот интерфейс реализовать. В общем, тот же смарт пойнтер реализуется безо всяких шаблонов, правда, типы нужно явно приводить

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

ST>Не нужно создавать дополнительный интерфейс на каждый чих. Можно сделать 1 интерфейс и 1 класс (смарт-пойнтер) в котором этот интерфейс реализовать. В общем, тот же смарт пойнтер реализуется безо всяких шаблонов, правда, типы нужно явно приводить

.
И типы надо явно приводить и менеджер памяти дергать и тащить виртуальность туда где мог быть инлайн и куча лишних действий... Зачем?

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

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

WH>>>А там все контейнеры это классы, а все классы создаются в хипе...
ST>>А есть языки где все суть есть класс

и дельфя ближе к ним.

WH>И какое это имеет отношение к обращениям к хипу которых могло и не быть?

Это из контекста вырвано, не помню о чем речь.

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

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

ST>>Согласен, но одно большое "НО":
ST>>Изначально разговор был о производительности. А тут мы экономим операцию записи в память за счет операции вызова функции (и не дай бог виртуальной — если через фабрику создавать).
ST>>Да, и не говорите мне пожалуйста об инлайн-расширении.
WH>Почему? В данном случае все очень хорошо инлайнится.

Но в общем случае не хорошо.

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

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

ST>>Не нужно создавать дополнительный интерфейс на каждый чих. Можно сделать 1 интерфейс и 1 класс (смарт-пойнтер) в котором этот интерфейс реализовать. В общем, тот же смарт пойнтер реализуется безо всяких шаблонов, правда, типы нужно явно приводить

.
WH>И типы надо явно приводить и менеджер памяти дергать и тащить виртуальность туда где мог быть инлайн и куча лишних действий... Зачем?

затем, что дельфу до конца не доделали — GC-то нетути

или, м.быть

Hello, s.ts!
You wrote on Fri, 17 Oct 2003 11:45:22 GMT:

s>

Но в делфи это поведение можно менять. ИМХО начальная
s> инициализация обеспечивает большую безопасность, а в дельфе она по
s> умолчанию включена. Это-то мне и нравится.

Да, от забывчивости иногда спасало бы. Но согласно идеологии С++ такая инициализация обязана быть отключаемой.

s> А когда начинаем борьбу
s> за производительность, то можно и отключить.

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

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

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

S>Hello, s.ts!
S>You wrote on Fri, 17 Oct 2003 11:45:22 GMT:

s>>

Но в делфи это поведение можно менять. ИМХО начальная
s>> инициализация обеспечивает большую безопасность, а в дельфе она по
s>> умолчанию включена. Это-то мне и нравится.

S>Да, от забывчивости иногда спасало бы. Но согласно идеологии С++ такая инициализация обязана быть отключаемой.

s>> А когда начинаем борьбу
s>> за производительность, то можно и отключить.

S>Только что мне кто-то в этом топике утверждал, что InitInstance вызывается всегда... Кому из вас верить?
Мне

class function TObject.NewInstance: TObject;//virtual
begin
  Result := InitInstance(_GetMem(InstanceSize));
end;

Newinstance вызывается всегда для выделения памяти под объект = TObject::operator new
Она виртувльная, так что как захотим так и будет. А то, что выше — это по умолчанию.

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

FWP>Про какой-такой Level. Уж не с FoxPro ли вы работаете? Какой ужас

К счастью работал, и не с Лисом, а DBase IV, Clipper понимаете

FWP>Я тот же путь проделал

И ничего хуже FoxPro не видел. Но это не самый большой грех MS. Самый большой — Windows

Как, а Access'95

А вообщето Лис лучше корабля, там SQL даже есть и визуальная среда, да и с базами лучше, да и с сетью тоже

FWP>Это "моё личное мнение, задеть ни кого не хотел

"

А насчет Винды, а куда без неё, юзьвери её любят

P.S. Ну не нравиться мне Борланд под ВыньДос и всё тут

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

F>Переходим на асм? Программы будут просто зашибись!

Долой асм

Даёшь машинные коды

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

WH>>>Людям лениво было помнить машинные коды — придумали асм
WH>>>Потом стало лениво писать на асме — придумали С
WH>>>...
FWP>>Согласен. Только уж пожалуйста продолжай, раз начал...

FWP>>Потом стало лениво писать на С — придумали С++
FWP>>Потом стало лениво писать на С++ — придумали ... Что придумали?

_>С#

Неа — VB придумали

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

WH>>И типы надо явно приводить и менеджер памяти дергать и тащить виртуальность туда где мог быть инлайн и куча лишних действий... Зачем?
ST>затем, что дельфу до конца не доделали — GC-то нетути

или, м.быть

?
Вот я и спрашиваю какого вы за эту недоделку держитесь? Да и ГЦ ей не сильно поможет.

... << RSDN@Home 1.1 beta 2 >>

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

WH>>Почему? В данном случае все очень хорошо инлайнится.

ST>Но в общем случае не хорошо.
Скажи это оптимизатору...
Вот довольно простая задачка для него...

... << RSDN@Home 1.1 beta 2 >>

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

WH>>И какое это имеет отношение к обращениям к хипу которых могло и не быть?
ST>Это из контекста вырвано, не помню о чем речь.
Re[14]: мнение о Delphi
Re[15]: мнение о Delphi
Поставь Янус.

... << RSDN@Home 1.1 beta 2 >>

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

M>Если я правильно ошибаюсь, в С с классами — сами классы тоже были объектами. Жаль что в С++ они не попали.

Ты об Objective C ?

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

WH>Вот я и спрашиваю какого вы за эту недоделку держитесь?

Не недоделку, а старушку... Да, есть некоторые неудобства, но к ним уже давно привык. Ну выделяются классы не в стеке, а в динамической памяти, ну и пусть. Все равно в 99% случаев скорость работы устраивает, а в 0.9% случаев и размещение в стеке не спасло бы. Основное --- с Delphi связано очень много приятных воспоминаний, а VB.NET, C#, C++ вызывают дискомфорт.

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

WH>ЗЗЫ на дельфи еще дольше. Ибо ни чего этот язык не умеет.

WH>ЗЗЗЫ а как ты думаешь почему С++ и жаба это промышленные стандарты?

Можно вопрос? А что умеет джава и не умеет Дельфи? И как быть с тем что умеет Дельфи и не умеет джава?

... << RSDN@Home 1.1 beta 2 (np: тихо) >>

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

ST>Есть некоторые вещи, касающиеся ООП, которые действительно лучше реализованы в дельфе. Как, например, вызов виртуальных функций из конструктора, RTTI (ну и, как следствие, виртуальные конструкторы)...

Ты уверен?

... << RSDN@Home 1.1 beta 2 (np: тихо) >>

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

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

WH>>ЗЗЫ на дельфи еще дольше. Ибо ни чего этот язык не умеет.

WH>>ЗЗЗЫ а как ты думаешь почему С++ и жаба это промышленные стандарты?

AVK>Можно вопрос? А что умеет джава и не умеет Дельфи?

Java стабильнее и не падает от "глупых" ошибок

WH>>ЗЗЗЫ а как ты думаешь почему С++ и жаба это промышленные стандарты?

AVK>Можно вопрос? А что умеет джава и не умеет Дельфи? И как быть с тем что умеет Дельфи и не умеет джава?

Можно я встряну?
Итак, чего не умеет Delphi и умеет Java (емеется ввиду возможности оригинальных/сторонних библиотек по тем или иным технологическим фичам):
— Delphi не умеет работать с полными состояниями объектов (сериализация как в Java), сохранение published-свойств наследников TComponent — жалкое подобие Java-сериализации — ничего кроме сохранения "внешнего" состояния, но не внутреннего не даёт;
— свои заморочки VCL по части работы с сокетами (приложения иногда просто "валятся" на элементарных операциях с сокетами);
— компонентный подход у обеих сред почти совпадает (наследники TComponent в Delphi; JavaBeans-парадигма в Java с наследованием от любого класса);
— в Delphi трудно программировать сложные многонитиевые приложения — много возни;
— в Delphi нет Layout-менеджеров размещения виджетов;
— в Delphi нет других стилей визуальных компонентов, кроме Window-ых (в Java есть одинаково выглядящие на любых платформах стили Swing, включающие Win/Motif/GTK/Metal/Mac);
— в Delphi нет фреймворка SecurityAPI чтобы быть независимым от MS-платформы;
— в Delphi нет понятия службы имён и каталогов для прозрачной конвергенции различных приложений как J2EE/JNDI, но есть, безусловно, доступ через (часто низкоуровневый) API к аналогичной ипостаси Windows/Registry&ActiveDirectory;
— в Delphi есть возможность создавать компоненты системы прикладного назначения: COM/DCOM/COM+ — похожее есть в J2SE (любой класс — аналог COM-компонента; RMI — почти аналог DCOM-технологии) и особенно в J2EE (EJB — расширенный аналог COM+, причём по ряду возможностей несравним);
— в Delphi нет такой фичи как самодокументирование кода и API (JavaDoc), хотя сторонние наработки есть, но они не совместимы;
— в Java больше настраиваешь, чем программируешь: байт-код один на всех платформах, но настроек всяких делаешь куда больше (я имею ввиду дескрипторы развёртывания, настройки JNDI, настройки RMI, J2EE);
— в Delphi невозможно "на лету" использовать какую-то другую технологию доступа к данным кроме системно-зависимых и проприетарных (закрытых) BDE/ADO/dbExpress;
— в Delphi возможно создание приложений только для Windows (о Kylix-технологии не будем говорить, так как всё равно код получается "не чистым").

Здравствуйте, DarkGray, Вы писали:
<...>
DG>Java стабильнее и не падает от "глупых" ошибок
Общий класс ошибок объектно-ориентированных языков — NullPointerException — обращение к несуществующему объекту.
Чаще встречается в Java из-за динамической природы языка.

ZEN>- в Delphi невозможно "на лету" использовать какую-то другую технологию доступа к данным кроме системно-зависимых и проприетарных (закрытых) BDE/ADO/dbExpress;

Беру свои вышеуказанные слова обратно взад.

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

ZEN>- Delphi не умеет работать с полными состояниями объектов (сериализация как в Java), сохранение published-свойств
ZEN> наследников TComponent — жалкое подобие Java-сериализации — ничего кроме сохранения "внешнего" состояния, но не внутреннего не даёт;

Следствие урезанности RTTI.

ZEN>- свои заморочки VCL по части работы с сокетами (приложения иногда просто "валятся" на элементарных операциях с сокетами);

Это проблемы библиотеки, а не языка.

ZEN>- в Delphi трудно программировать сложные многонитиевые приложения — много возни;

В Java меньше? Ты считаешь lock большим достижением? На самом деле простейшая синтаксическая обертка, полный аналог

Locker.EnterCriticalSection(obj);
try
{
...
}
finally
{
Locker.LeaveCriticalSection(obj);
}

ZEN>- в Delphi нет Layout-менеджеров размещения виджетов;

Это особенности библиотеки

ZEN>- в Delphi нет других стилей визуальных компонентов, кроме Window-ых (в Java есть одинаково выглядящие на любых платформах стили Swing, включающие Win/Motif/GTK/Metal/Mac);

Это особенности библиотеки

ZEN>- в Delphi нет фреймворка SecurityAPI чтобы быть независимым от MS-платформы;

Это особенности библиотеки

ZEN>- в Delphi нет понятия службы имён и каталогов для прозрачной конвергенции различных приложений как J2EE/JNDI, но есть, безусловно, доступ через (часто низкоуровневый) API к аналогичной ипостаси Windows/Registry&ActiveDirectory;

Это особенности библиотеки

ZEN>- в Delphi есть возможность создавать компоненты системы прикладного назначения: COM/DCOM/COM+ — похожее есть в J2SE (любой класс — аналог COM-компонента; RMI — почти аналог DCOM-технологии) и особенно в J2EE (EJB — расширенный аналог COM+, причём по ряду возможностей несравним);

Это особенности библиотеки

ZEN>- в Delphi нет такой фичи как самодокументирование кода и API (JavaDoc), хотя сторонние наработки есть, но они не совместимы;

Согласен

ZEN>- в Java больше настраиваешь, чем программируешь: байт-код один на всех платформах, но настроек всяких делаешь куда больше (я имею ввиду дескрипторы развёртывания, настройки JNDI, настройки RMI, J2EE);

Это какая то мутная философия. Неконкретно.

ZEN>- в Delphi возможно создание приложений только для Windows (о Kylix-технологии не будем говорить, так как всё равно код получается "не чистым").

Это свойства не языка, а платформы.

... << RSDN@Home 1.1 beta 2 (np: тихо) >>

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

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

ZEN>>- Delphi не умеет работать с полными состояниями объектов (сериализация как в Java), сохранение published-свойств
ZEN>> наследников TComponent — жалкое подобие Java-сериализации — ничего кроме сохранения "внешнего" состояния, но не внутреннего не даёт;
AVK>Следствие урезанности RTTI.

Нифига подобного. Reflection (получение сигнатур методов) можно реализовать в Delphi, а значит и полную сериализацию.

ZEN>>- свои заморочки VCL по части работы с сокетами (приложения иногда просто "валятся" на элементарных операциях с сокетами);
AVK>Это проблемы библиотеки, а не языка.
Согласен.

ZEN>>- в Delphi трудно программировать сложные многонитиевые приложения — много возни;
AVK>В Java меньше? Ты считаешь lock большим достижением? На самом деле простейшая синтаксическая обертка, полный аналог
<...>
Несовсем.
Есть такие вещи вещи в Java как монитор объекта, который встроен на уровне базового класса java.lang.Object и позволяет творить чудеса без затрат процессорного времени (я имею ввиду технику на основе методов wait()/notify()/notifyAll()).
А вот простейший мьютекс мы получаем, используя лишь экземпляр класса java.lang.Object.

ZEN>>- в Delphi нет Layout-менеджеров размещения виджетов;
AVK>Это особенности библиотеки
Угу. В Java же "одного мира мало".

ZEN>>- в Delphi нет других стилей визуальных компонентов, кроме Window-ых (в Java есть одинаково выглядящие на любых платформах стили Swing, включающие Win/Motif/GTK/Metal/Mac);
AVK>Это особенности библиотеки
Аналогично (см. выше)

ZEN>>- в Delphi нет фреймворка SecurityAPI чтобы быть независимым от MS-платформы;
AVK>Это особенности библиотеки
Аналогично (см. выше)

ZEN>>- в Delphi нет понятия службы имён и каталогов для прозрачной конвергенции различных приложений как J2EE/JNDI, но есть, безусловно, доступ через (часто низкоуровневый) API к аналогичной ипостаси Windows/Registry&ActiveDirectory;
AVK>Это особенности библиотеки
Аналогично (см. выше)

ZEN>>- в Delphi есть возможность создавать компоненты системы прикладного назначения: COM/DCOM/COM+ — похожее есть в J2SE (любой класс — аналог COM-компонента; RMI — почти аналог DCOM-технологии) и особенно в J2EE (EJB — расширенный аналог COM+, причём по ряду возможностей несравним);
AVK>Это особенности библиотеки
Аналогично (см. выше)
<...>
ZEN>>- в Java больше настраиваешь, чем программируешь: байт-код один на всех платформах, но настроек всяких делаешь куда больше (я имею ввиду дескрипторы развёртывания, настройки JNDI, настройки RMI, J2EE);
AVK>Это какая то мутная философия. Неконкретно.
Почему?
Вопросы развёртывания продуктов играют не последнюю скрипку. Трудоёмкость здесь тоже есть и разная!
Для Delphi-приложения достаточно INI-файла (для Java-приложения аналог — properties-файл), но когда Delphi-приложение "общается" с персистентным хранилищем системы (registry), то для Java аналогичная "фича" — JNDI — вот тут-то и начинаются пляски с бубном, но, естественно, всё зависит от приложения, его "степени настраиваемости".

ZEN>>- в Delphi возможно создание приложений только для Windows (о Kylix-технологии не будем говорить, так как всё равно код получается "не чистым").
AVK>Это свойства не языка, а платформы.

Ага. Согласен.
Тогда будет правильнее говорить о Windows vs. Java.

ZEN>- свои заморочки VCL по части работы с сокетами (приложения иногда просто "валятся" на элементарных операциях с сокетами);

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

ZEN>- в Delphi нет других стилей визуальных компонентов, кроме Window-ых (в Java есть одинаково выглядящие на любых платформах стили Swing, включающие Win/Motif/GTK/Metal/Mac);

QT в CLX_Applications этого не умеют?

ZEN>- в Delphi невозможно "на лету" использовать какую-то другую технологию доступа к данным кроме системно-зависимых и проприетарных (закрытых) BDE/ADO/dbExpress;

Да ну? А как же огромное кол-во "компонент прямого доступа" к IB/MSSQL/Oracle/etc ?
Почему вдруг dbExpress оказался системно-зависимым?

ZEN>- в Delphi возможно создание приложений только для Windows (о Kylix-технологии не будем говорить, так как всё равно код получается "не чистым").

Не очень понятно. То, что Qt используется?

P.S. Я не встреваю в ваш спор, что лучше, просто мне показались спорными именно эти моменты.

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

ZEN>>- свои заморочки VCL по части работы с сокетами (приложения иногда просто "валятся" на элементарных операциях с сокетами);
iT>Не думаю, что это можно отнести на счет самой Delphi, тем более, что есть множество сторонних библиотек работы с сокетами.
Да, безусловно. Но то, что есть в VCL...

ZEN>>- в Delphi нет других стилей визуальных компонентов, кроме Window-ых (в Java есть одинаково выглядящие на любых платформах стили Swing, включающие Win/Motif/GTK/Metal/Mac);
iT>QT в CLX_Applications этого не умеют?
Не знаю, не пробовал.
Разве QT умеет "прикидываться" Win/Motif/GTK/Metal/Mac на Linux.
А для Windows тоже есть QT-порт, с которым работают CLX_Applications?
Я хотел сказать, что Swing умеет выглядеть, напрмер, CDE-подобным (UNIX/Motif) на любых платформах, где может работать Java.

ZEN>>- в Delphi невозможно "на лету" использовать какую-то другую технологию доступа к данным кроме системно-зависимых и проприетарных (закрытых) BDE/ADO/dbExpress;
iT>Да ну? А как же огромное кол-во "компонент прямого доступа" к IB/MSSQL/Oracle/etc ?
Я уже взял свои слова на этот счёт "обратно в зад" в одном из предыдущих высказываний.

iT>Почему вдруг dbExpress оказался системно-зависимым?
Драйверы в каком исполнении распространяются? Драйверы в виде Dll — для Windows, ...- для Linux (дополните фразу). Тогда и поговорим.

ZEN>>- в Delphi возможно создание приложений только для Windows (о Kylix-технологии не будем говорить, так как всё равно код получается "не чистым").
iT>Не очень понятно. То, что Qt используется?
Вы уверены, что CLX-приложения после перекомпиляции на обоих платформах (Windows, Linux) будут работать одинаково? Это в идеале...

iT>P.S. Я не встреваю в ваш спор, что лучше, просто мне показались спорными именно эти моменты.
А Вы встряньте! Хочется общения.

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

DG>>Java стабильнее и не падает от "глупых" ошибок
ZEN>Общий класс ошибок объектно-ориентированных языков — NullPointerException — обращение к несуществующему объекту.
ZEN>Чаще встречается в Java из-за динамической природы языка.

При наличии Call Stack локализовать ошибку легко, а затирание памяти очень тяжело ищется.

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

AVK>>Следствие урезанности RTTI.

ZEN>Нифига подобного. Reflection (получение сигнатур методов) можно реализовать в Delphi,
ZEN>а значит и полную сериализацию.

Ничего кроме published свойств через RTTI недоступно, значит никакой автоматической сериализации и никакого рефлекшена.

ZEN>>>- в Delphi трудно программировать сложные многонитиевые приложения — много возни;
AVK>>В Java меньше? Ты считаешь lock большим достижением? На самом деле простейшая синтаксическая обертка, полный аналог
<...>>
ZEN>Несовсем.

Совсем совсем

ZEN>Есть такие вещи вещи в Java как монитор объекта,

Есть. Locker в моем примере. Реализуется на коленке за полчаса.

ZEN> который встроен на уровне базового класса java.lang.Object и позволяет творить чудеса без затрат процессорного времени (я имею ввиду технику на основе методов wait()/notify()/notifyAll()).

Не знаю как в джаве, а вот в дотнете lock это чисто синтаксическая фишка, анализ сгенеренного кода ildasm'ом это подтверждает. Возможности lock идентичны джавовским. Да и не понятно зачем лок встраивать в базовый класс.

ZEN>>>- в Java больше настраиваешь, чем программируешь: байт-код один на всех платформах, но настроек всяких делаешь куда больше (я имею ввиду дескрипторы развёртывания, настройки JNDI, настройки RMI, J2EE);
AVK>>Это какая то мутная философия. Неконкретно.
ZEN>Почему?

Не знаю, у тебя надо спросить

ZEN>Вопросы развёртывания продуктов играют не последнюю скрипку. Трудоёмкость здесь тоже есть и разная!
ZEN>Для Delphi-приложения достаточно INI-файла (для Java-приложения аналог — properties-файл), но когда Delphi-приложение "общается" с персистентным хранилищем системы (registry), то для Java аналогичная "фича" — JNDI

Ты чего то путаешь. Registry это просто хранилище данных. Аналог в джаве это тектовый xml.

ZEN> — вот тут-то и начинаются пляски с бубном, но, естественно, всё зависит от приложения, его "степени настраиваемости".

Опять же непонятно каким боком тут виноват язык. Платформа, библиотека возможно, но никак не язык.

ZEN>Ага. Согласен.
ZEN>Тогда будет правильнее говорить о Windows vs. Java.

Нет, не правильнее. Перечитай сообщение, на которое я отвечал.

... << RSDN@Home 1.1 beta 2 (np: тихо) >>

ZEN>Вы уверены, что CLX-приложения после перекомпиляции на обоих платформах (Windows, Linux) будут работать одинаково? Это в идеале...

Хочешь сказать, что на Java любые приложения будут работать на любой системе?
Это в идеале...

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

iT>Хочешь сказать, что на Java любые приложения будут работать на любой системе?
Не надо так утрировать — ведь всё зависит от окружения, библиотек в первую очередь.
А вот форматы class-файлов одни и те же что для мобильных телефонов, что для серверов приложений J2EE — один компилятор используется для разных аппаратных платформ, байт-код одинаковый.
iT>Это в идеале...

таки да.

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

B>Как, а Access'95

Чур меня! Пока Бог миловал. Доводилось только переделывать Access поделки на другие платформы.

B>А вообщето Лис лучше корабля, там SQL даже есть и визуальная среда, да и с базами лучше, да и с сетью тоже.
А вот это спорно. Особенно насчет сети.

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

B>>А вообщето Лис лучше корабля, там SQL даже есть и визуальная среда, да и с базами лучше, да и с сетью тоже.
FWP>А вот это спорно. Особенно насчет сети.

Clipper vs FoxPro — это круто

Динозавры поспорим

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

ZEN>Разве QT умеет "прикидываться" Win/Motif/GTK/Metal/Mac на Linux.
Да.
ZEN>А для Windows тоже есть QT-порт, с которым работают CLX_Applications?
Да.
ZEN>Я хотел сказать, что Swing умеет выглядеть, напрмер, CDE-подобным (UNIX/Motif) на любых платформах, где может работать Java.
Вот и с qt то же самое.

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

B>Clipper vs FoxPro — это круто

B>Динозавры поспорим

Запросто!

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

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

B>>Clipper vs FoxPro — это круто

B>>Динозавры поспорим

FWP>Запросто!

Тогда надо в священные войны переходить

.
Только, мне они оба (и лис, и корабль) нравились одинаково

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

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

WH>>Вот я и спрашиваю какого вы за эту недоделку держитесь?

M>Не недоделку, а старушку... Да, есть некоторые неудобства, но к ним уже давно привык. Ну выделяются классы не в стеке, а в динамической памяти, ну и пусть. Все равно в 99% случаев скорость работы устраивает, а в 0.9% случаев и размещение в стеке не спасло бы. Основное --- с Delphi связано очень много приятных воспоминаний, а VB.NET, C#, C++ вызывают дискомфорт.

После Delphi, конечно, C++ — сложнее и используемые приемы кажутся надуманными.
Много времени уходит на синтаксис.
И пусть уж все хорошо, но MFC

и иже с ними ...

С# — это

Что вызывает дискомфорт — это Java — там все как-то иначе и не факт, что лучше. .NET имеет больше общих корней с Delphi. Так что, будем перетекать...

и дельфя ближе к ним.

WH>И какое это имеет отношение к обращениям к хипу которых могло и не быть?

это я не закончил : " ... и есть GC и все располагается в хипе "

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

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

ZEN>>Разве QT умеет "прикидываться" Win/Motif/GTK/Metal/Mac на Linux.
_>Да.
ZEN>>А для Windows тоже есть QT-порт, с которым работают CLX_Applications?
_>Да.
ZEN>>Я хотел сказать, что Swing умеет выглядеть, напрмер, CDE-подобным (UNIX/Motif) на любых платформах, где может работать Java.
_>Вот и с qt то же самое.

Ни у кого нет сомнений, что C++ умеет все ????
Дык вот, мы тут дельфу с С++ сравниваем... Так что с жабой лучше и не лезте

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

ST>После Delphi, конечно, C++ — сложнее и используемые приемы кажутся надуманными.

Ну... Первым моим языком программирования был Turbo C 1.5, а уже потом Pascal. Одной из причин перехода явилось корявое поведение Turbo Vision из-под Borland C++ 3.1. А потом... не знаю... С выходом Delphi 3, я с Delphi не слезаю. Сейчас пишу на VB под ASP.NET, но чувствую, что скоро лопнет терпение, и пойду работать грузчиком...

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

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

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

WH>>>>А там все контейнеры это классы, а все классы создаются в хипе...
ST>>>А есть языки где все суть есть класс

и дельфя ближе к ним.

WH>>И какое это имеет отношение к обращениям к хипу которых могло и не быть?

ST>это я не закончил : " ... и есть GC и все располагается в хипе "

Что значит "все располагается в хипе"?

... << RSDN@Home 1.1 beta 1 >>

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

ВВ>Здравствуйте, s.ts, Вы писали:

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

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

WH>>>>>А там все контейнеры это классы, а все классы создаются в хипе...
ST>>>>А есть языки где все суть есть класс

и дельфя ближе к ним.

WH>>>И какое это имеет отношение к обращениям к хипу которых могло и не быть?

ST>>это я не закончил : " ... и есть GC и все располагается в хипе "

ВВ>Что значит "все располагается в хипе"?

имхо :
объекты пользовательских non-final классов
или иначе :
все они где-то хранятся и плевать мне где — пусть VM-девелоперы об этом позаботятся, чтобы я не думал и флеймов не раздувал

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

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

ST>>После Delphi, конечно, C++ — сложнее и используемые приемы кажутся надуманными.

M>Ну... Первым моим языком программирования был Turbo C 1.5, а уже потом Pascal. Одной из причин перехода явилось корявое поведение Turbo Vision из-под Borland C++ 3.1. А потом... не знаю... С выходом Delphi 3, я с Delphi не слезаю. Сейчас пишу на VB под ASP.NET, но чувствую, что скоро лопнет терпение, и пойду работать грузчиком...

У меня 2-м был TurboPascal. Потом начитался Cтрауструпа — перетек на C++ (в турбопаскале тогда не было ооп). Год назад пришлось пересесть на дельфи. Мечта — пересесть на bat-файлы и больше не мучаться. Пока есть ощущение правильности пути, выбранного для достижения своей мечты (до bat-файлов мне еще далеко — нужно много работать, но уже посматриваю на java и .NET).

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

ST>У меня 2-м был TurboPascal. Потом начитался Cтрауструпа — перетек на C++ (в турбопаскале тогда не было ооп). Год назад пришлось пересесть на дельфи. Мечта — пересесть на bat-файлы и больше не мучаться. Пока есть ощущение правильности пути, выбранного для достижения своей мечты (до bat-файлов мне еще далеко — нужно много работать, но уже посматриваю на java и .NET).

Как замена bat-ников?

Здравствуйте, sergei74ap, Вы писали:
Давайте уже слезем с Object Pascal! Если всю эту дискуссию выжать как следует, то будет неплохой курс типа "чем отличается объектная модель Delphi от таковой в С++". Хотя наиболее тяжкие преступления разработчиков компилера Delphi даже не были затронуты.

Давайте лучше перейдем к обсуждению VCL. Я т ут недавно совершенно случайно задумался, и понял, что в данный момент эта библиотека совершенно устарела архитектурно. Самый ужас в том, что многие ее черты были слепо перенесены в WinForms. Как вы думаете, можно ли написать альтернативную VCL, опираясь на голый Object Pascal (т.е. имеем только TObject)? При этом избежав этих ужасных Anchors, Alignment и AutoSize?

... << RSDN@Home 1.1 beta 2 >>

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

S>Давайте лучше перейдем к обсуждению VCL. Я т ут недавно совершенно случайно задумался, и понял, что в данный момент эта библиотека совершенно устарела архитектурно. Самый ужас в том, что многие ее черты были слепо перенесены в WinForms. Как вы думаете, можно ли написать альтернативную VCL, опираясь на голый Object Pascal (т.е. имеем только TObject)? При этом избежав этих ужасных Anchors, Alignment и AutoSize?

Почему ты считаешь Anchors, Alignment ужасными?

Здравствуйте, Lloyd, Вы писали:
L>Почему ты считаешь Anchors, Alignment ужасными?

А ты посмотри на поведение формы с достаточно сложной структурой — сплиттерами, фреймами и прочими вещами — при ресайзе с включенным Redraw Window Contents When Resize. Совместно с MinMAxInfo, OnRequestResize и OnSize это сущий кошмар.
Весь смысл в том, что с точки зрения архитектуры упраеление взаимным размещением окон в контейнере при помощи свойств самих окон — бред. Бадная среда вынуждена итеративно решать систему неравенств, чтобы найти более-менее приемлемое решение. Именно эта часть VCL подвергалась значительным изменениям с каждой новой версией.

... << RSDN@Home 1.1 beta 2 >>

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

S>Весь смысл в том, что с точки зрения архитектуры упраеление взаимным размещением окон в контейнере при помощи свойств самих окон — бред.

Формы с "достаточно сложной структорой" это ужас с точки зрения юзабилити. Проще надо быть, проще. И юезры к Вам потянутся.

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

S>А ты посмотри на поведение формы с достаточно сложной структурой — сплиттерами, фреймами и прочими вещами — при ресайзе с включенным Redraw Window Contents When Resize. Совместно с MinMAxInfo, OnRequestResize и OnSize это сущий кошмар.
S>Весь смысл в том, что с точки зрения архитектуры упраеление взаимным размещением окон в контейнере при помощи свойств самих окон — бред. Бадная среда вынуждена итеративно решать систему неравенств, чтобы найти более-менее приемлемое решение. Именно эта часть VCL подвергалась значительным изменениям с каждой новой версией.

Ты предлагаешь из-за этого совсем отказаться от Anchors и Alignment-а?
И реализовывать весь этот "бред" руками?

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

S>Здравствуйте, sergei74ap, Вы писали:
S>Давайте уже слезем с Object Pascal! Если всю эту дискуссию выжать как следует, то будет неплохой курс типа "чем отличается объектная модель Delphi от таковой в С++". Хотя наиболее тяжкие преступления разработчиков компилера Delphi даже не были затронуты.

А какие ?

S>Давайте лучше перейдем к обсуждению VCL. Я т ут недавно совершенно случайно задумался, и понял, что в данный момент эта библиотека совершенно устарела архитектурно. Самый ужас в том, что многие ее черты были слепо перенесены в WinForms. Как вы думаете, можно ли написать альтернативную VCL, опираясь на голый Object Pascal (т.е. имеем только TObject)? При этом избежав этих ужасных Anchors, Alignment и AutoSize?

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

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

S>>Весь смысл в том, что с точки зрения архитектуры упраеление взаимным размещением окон в контейнере при помощи свойств самих окон — бред.

_>Формы с "достаточно сложной структорой" это ужас с точки зрения юзабилити. Проще надо быть, проще. И юезры к Вам потянутся.

Может эти формы имеют "достаточно сложную структуру" как раз из-за того, что при их создании стремились к юзабилити.

... << RSDN@Home 1.1 beta 1 >>

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

L>Ты предлагаешь из-за этого совсем отказаться от Anchors и Alignment-а?
L>И реализовывать весь этот "бред" руками?

Нет, я предлагаю пересмотреть архитектурную модель. Так, чтобы окна и сплиттеры не болтались в форме, как г. в проруби, а представляли из себя четкое дерево, позволяющее однозначно решить задачу назначения размеров. В библиотеке, ессно!

... << RSDN@Home 1.1 beta 2 >>

Здравствуйте, zaiats_2k, Вы писали:
_>Формы с "достаточно сложной структорой" это ужас с точки зрения юзабилити. Проще надо быть, проще. И юезры к Вам потянутся.

Ну как вам сказать, заяц... Вот windows explorer — это с точки зрения юзаюилити как? А ведь реализация чего-то подобного уже начнет плавать и трепыхаться. А уж про простейшие аутлуковые формы (в юзабилити каждой из который вложено больше средств, чем мы c вами вместе заработали) простым девелоперам можно забыть — в терминах VCL их особо не разбежишься реализовывать.

... << RSDN@Home 1.1 beta 2 >>

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

S>Здравствуйте, zaiats_2k, Вы писали:
_>>Формы с "достаточно сложной структорой" это ужас с точки зрения юзабилити. Проще надо быть, проще. И юезры к Вам потянутся.

S>Ну как вам сказать, заяц... Вот windows explorer — это с точки зрения юзаюилити как? А ведь реализация чего-то подобного уже начнет плавать и трепыхаться. А уж про простейшие аутлуковые формы (в юзабилити каждой из который вложено больше средств, чем мы c вами вместе заработали) простым девелоперам можно забыть — в терминах VCL их особо не разбежишься реализовывать.

Как, неужели вот прямо так сразу и начнут плавать две панели и сплиттер между ними!? Может я конечно что-то не так делаю, но у меня и три панели (как в аутлуке) не плавают...

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

ST>А какие ?
Э-э-х. Поклянитесь, что флейма не будет!
Задачка:

...
  MyObject = GetMyObject(SomeParam);
    MyObject.SomeMethod('TestParam');

Внимание, вопрос: если компилятор успешног компилирует этот код, означает ли это, что MyObject оборудован методом SomeMethod с одним строковм параметром?
Правильный ответ — нет. Если переменная MyObject имеет тип Variant, то после точки можно написать все, что угодно.
Это низводит Object Pascal с возвышения, на котором сидят строго типизированные языки, и вводит в детский манеж, отведенный для всяких скриптовых товарищей типа VB и JScript.

... << RSDN@Home 1.1 beta 2 >>

ST>>это я не закончил : " ... и есть GC и все располагается в хипе "

ВВ>Что значит "все располагается в хипе"?

Вообще — всё

S>Ну как вам сказать, заяц... Вот windows explorer — это с точки зрения юзаюилити как? А ведь реализация чего-то подобного уже начнет плавать и трепыхаться. А уж про простейшие аутлуковые формы (в юзабилити каждой из который вложено больше средств, чем мы c вами вместе заработали) простым девелоперам можно забыть — в терминах VCL их особо не разбежишься реализовывать.

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

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

ST>>>это я не закончил : " ... и есть GC и все располагается в хипе "

ВВ>>Что значит "все располагается в хипе"?

dad>Вообще — всё

Matrix has you

что в переводе на русский:

Матрица имеет тебя

... << RSDN@Home 1.1 beta 1 >>

Здравствуйте, zaiats_2k, Вы писали:
_>Как, неужели вот прямо так сразу и начнут плавать две панели и сплиттер между ними!? Может я конечно что-то не так делаю, но у меня и три панели (как в аутлуке) не плавают...

Да, начнут. Как только у вас появятся нетривиальные комбинации Constraints и прочих радостей. А более сложные модельки вообще накроются медным тазом. Если хочется, я могу нарисвать форму на VCL, которая будет вести себя достаточно хреново — по мотивам одного их моих старых проектов.

... << RSDN@Home 1.1 beta 2 >>

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

S>Здравствуйте, zaiats_2k, Вы писали:
_>>Как, неужели вот прямо так сразу и начнут плавать две панели и сплиттер между ними!? Может я конечно что-то не так делаю, но у меня и три панели (как в аутлуке) не плавают...

S>Да, начнут. Как только у вас появятся нетривиальные комбинации Constraints и прочих радостей. А более сложные модельки вообще накроются медным тазом. Если хочется, я могу нарисвать форму на VCL, которая будет вести себя достаточно хреново — по мотивам одного их моих старых проектов.

Рисовать не стоит, всё равно у меня Delphi не стоит... Лучше покажи мне, где в Windows Explorer ты нашёл "constraints и прочие радости"?

Здравствуйте, zaiats_2k, Вы писали:
_>Рисовать не стоит, всё равно у меня Delphi не стоит... Лучше покажи мне, где в Windows Explorer ты нашёл "constraints и прочие радости"?

Ну как же! Task/Places Pane нельзя сресайзить меньше, чем она есть. Поведение TaskBar вообще довольно сложное — там мало того, что для его бандов известны минимальный и максимальный размеры, еще и ограничивается шаг квантования размера (при необходимости). Воспроизвести такую хрень при помощи алигнментов и сплиттеров нельзя.

... << RSDN@Home 1.1 beta 2 >>

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

S>Здравствуйте, zaiats_2k, Вы писали:
_>>Рисовать не стоит, всё равно у меня Delphi не стоит... Лучше покажи мне, где в Windows Explorer ты нашёл "constraints и прочие радости"?

S>Ну как же! Task/Places Pane нельзя сресайзить меньше, чем она есть.

Зато главное окошко можно сресайзить так что только заголовок окна виден будет.

S>Поведение TaskBar вообще довольно сложное — там мало того, что для его бандов известны минимальный и максимальный размеры, еще и ограничивается шаг квантования размера (при необходимости). Воспроизвести такую хрень при помощи алигнментов и сплиттеров нельзя.

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

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

_>TaskBar вещь очень специфическая, воспроизводить его в приложениях... я не знаю зачем это нужно.
Мы говорим не о том, что нужно в приложениях, а о том, что модель описания layout в VCL внутренне противоречива. Аргумент "а вот это просто не нужно" надо применять с большой осторожностью. Не хотелось бы придумывать ограничения без необходимости.

... << RSDN@Home 1.1 beta 2 >>

L>>Почему ты считаешь Anchors, Alignment ужасными?

S>А ты посмотри на поведение формы с достаточно сложной структурой — сплиттерами, фреймами и прочими вещами — при ресайзе с включенным Redraw Window Contents When Resize. Совместно с MinMAxInfo, OnRequestResize и OnSize это сущий кошмар.
S>Весь смысл в том, что с точки зрения архитектуры упраеление взаимным размещением окон в контейнере при помощи свойств самих окон — бред.

Родной! Так фишка же в том, что ты можешь не использовать эти навороты!
Встретился тебе необычный случай — ну реализуй ты Layout ручками...
Главное — что в простых случаях можно быстро и вполне качественно сделать!

Типичный довод противников Delphi — дескать, в сложных случаях, если делать все по книжке — то получается Г... Ну, блин, а вы чего хотели? Это же сложный случай!

Зато простой можно сделать быстро, легко и красиво.

Мне вот например, иногда не хватает в WinForms дельфийских Constraint'ов.

S>Это низводит Object Pascal с возвышения, на котором сидят строго типизированные языки, и вводит в детский манеж, отведенный для всяких скриптовых товарищей типа VB и JScript.

Неверно.
Скрипты так обходятся со ВСЕМИ переменными. А Delphi — строго тпизирован с нормальными данными. А редкий и особый случай с IDIspatch — ну извините, это следует из самой идеологии позднего связывания, что может не найтись такого метода.

Здравствуйте, Igor Trofimov, Вы писали:
iT>Родной! Так фишка же в том, что ты можешь не использовать эти навороты!
iT>Встретился тебе необычный случай — ну реализуй ты Layout ручками...
Фишка в том, родной, что хочется состряпать библиотеку, коя и простые, и сложные случаи эффективно покроет. А то у нас с одной стороны имеется вроде как бы RAD, а с другой — явные пробуксовки модели, как только выйдешь из фолдера Samples. Я=то хочу не рожать кажный раз в муках этот Layout, выписывая километровые TForm1.Form*Size
iT>Главное — что в простых случаях можно быстро и вполне качественно сделать!
iT>Типичный довод противников Delphi — дескать, в сложных случаях, если делать все по книжке — то получается Г... Ну, блин, а вы чего хотели? Это же сложный случай!
Ты бы меня в противники Delphi так бодро не записывал, родной. Я против бездумного поклонения VCL. Ежели б все было так хорошо, то Borland бы остановился еще версий пять назад. Мне не нравится, что библиотека тащит за собой очень много решений, которые применяются из-за совместимости.
iT>Мне вот например, иногда не хватает в WinForms дельфийских Constraint'ов.
список того, чего не хватает в WinForms, можно продолжать очень долго.

... << RSDN@Home 1.1 beta 2 >>

S>Фишка в том, родной, что хочется состряпать библиотеку, коя и простые, и сложные случаи эффективно покроет.

Уже видел такое где-нибудь?

S>Я против бездумного поклонения VCL.

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

S>Мне не нравится, что библиотека тащит за собой очень много решений, которые применяются из-за совместимости.

Увы, сама Delphi уже очень много тянет из-за совместимости ;(
СЕЙЧАС бы они VCL написали СОВСЕМ по-другому...

S>список того, чего не хватает в WinForms, можно продолжать очень долго.

Ну давай что-ли

Это кстати, действительно интересно — кому чего не хватает в WinForms по сравнению с Delphi. Думаю, всякие TPanel и прочую лабуду верхнего уровня, которые можно написать или найти мы считать не будем. Интересны решения уровнем пониже, то, что встроено в стандартную библиотеку.

Итак?

Согласен. А еще — очень некрасиво выглядит отрисовка (при перемещении каких-либо элементов) в случае, когда одни элементы программно (в виде пользовательцкой реакции на события) привязываются к другим. Дискретность перемещения (и прорисовки) у всех элементов получается различной.

Slicer

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

S>>Хотя наиболее тяжкие преступления разработчиков компилера Delphi даже не были затронуты.

ST>А какие ?

Ну как же! Не знаешь что ли? D6 уделало VC++6 по всем параметрам. Чем не УЖАСНОЕ преступление?

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

dad>Я лично дельфи не люблю, но от о юзабилити форм оутлука вы зря сказали.. Трудно себе представить более не удобного постового клиента. Я использую зе бат
Надо ж! Как неудачно. THE BAT написан как раз на той самой Delphi.

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

FWP>Ну как же! Не знаешь что ли? D6 уделало VC++6 по всем параметрам. Чем не УЖАСНОЕ преступление?
Огласите весь список пожалуйста.

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

ST>перегрузки операторов
Перегрузка операторов есть в фрипаскале

, мне он кстати болше нравится чем делфи.

Калабухов А.В.

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

iT>Итак?
Ну, мне интереснее то, чего не хватает в Dephi по сравнению с идеалом

Я не так много знаю других библиотек, заточенных как на RAD, так и на расширение.
Я бы в первую очередь переписал концепции Layout. По крайней мере, разделил бы окна на контейнерные окна и примитивные. И оставил бы в примитивных окнах только свойства, отвечающие за их размеры. А взаимное расположение окон вынес бы в контейнерные окна. Тогда сплиттер, как отдельный компонент, просто бы исчез, а вместо него были бы non-client зоны контейнера.

... << RSDN@Home 1.1 beta 2 >>

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

S>Часто приходится слышать мнение, что разработчики, использующие delphi -
S>ваще не программисты, а так... детишки неразумные.
В основном дело конечно в новичках, которые очень быстро могут слабать на дельфи что-то якобы работающее. Да и не только в новичках, многие люди уже несколько лет на дельфи пишут такуую муть

И она работает

и продается

Только я тут недавно помогал разгребать один такой проект: ну это просто какое-то

Я имел довольно мало дела с дельфи. Но тем не менее успел заметить, что то ли RAD вообще, то ли именно дельфи провоцирует на плохую архитектуру. Без разделения данные/представление, без разбиения на небольшие классы, даже без разбиения на отдельные функции. Куча народу пишет код только в нагенеренных средой функциях.

Кроме того дельфи провоцирует знать как можно меньше. Я знаю человека, который пользуется сокетами из VCL, т.к. считает, что это намного ( очень намного ) проще, чем с нормальными сокетами, а на сами сокеты так и не взглянул.

Дельфи провоцирует делать простое сложным. Например простой график рисовать через TChart ( ну и штука, я тут против воли познакомился недавно ).

S>Ясно, что у нее (как и у каждого ср-ва разработки) есть свои минусы,
S>но и плюсы тоже имеются.
Нормальный программист напишет на дельфи нормально, а не программист напишет как подсказывает среда и у него что-то получится. Это что-то будет кривым и косым, но будет работать. Это плюс или минус? Не знаю. Но точно повод настороженно относиться к программерам на дельфи: а вдруг он и не программер вовсе.

S>И что, об этом лучше никому не говорить?
Ну, работодатели в большинстве своем разумные люди.

... << RSDN@Home 1.1 beta 2 >>

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

Нет уж увольте. к IDispatch это не имеет никакого отношения. Я бы простил, если бы они так обходились с переменными типа IDispatch. Но когда компилируется вот такой код:
var
  A: variant;
begin
  A:= 5;
    A.LateBoundCall(SomeValue).OtherCall;
end;

я считаю это преступлением.

... << RSDN@Home 1.1 beta 2 >>

Hello, Sinclair!
You wrote on Wed, 22 Oct 2003 09:53:54 GMT:

S> Ну, мне интереснее то, чего не хватает в Dephi по сравнению с идеалом

S> Я не так много знаю других библиотек, заточенных как на RAD, так и на
S> расширение. Я бы в первую очередь переписал концепции Layout. По крайней
S> мере, разделил бы окна на контейнерные окна и примитивные. И оставил бы
S> в примитивных окнах только свойства, отвечающие за их размеры. А
S> взаимное расположение окон вынес бы в контейнерные окна. Тогда сплиттер,
S> как отдельный компонент, просто бы исчез, а вместо него были бы
S> non-client зоны контейнера.

IMHO, за layout отвечать должны отдельные классы, которые вообще не окна. Например так, как это сделано в wxWindows.

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

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

S>Hello, Sinclair!
S>You wrote on Wed, 22 Oct 2003 09:53:54 GMT:

S>> Ну, мне интереснее то, чего не хватает в Dephi по сравнению с идеалом

S>> Я не так много знаю других библиотек, заточенных как на RAD, так и на
S>> расширение. Я бы в первую очередь переписал концепции Layout. По крайней
S>> мере, разделил бы окна на контейнерные окна и примитивные. И оставил бы
S>> в примитивных окнах только свойства, отвечающие за их размеры. А
S>> взаимное расположение окон вынес бы в контейнерные окна. Тогда сплиттер,
S>> как отдельный компонент, просто бы исчез, а вместо него были бы
S>> non-client зоны контейнера.

S>IMHO, за layout отвечать должны отдельные классы, которые вообще не окна. Например так, как это сделано в wxWindows.

Я только одного не понимаю, кто мешает вам изобрести порох непромокаемый!? Ну сядьте и напишите, раз вас так эта проблема волнует! А мы потом посмотрим что лучше, анкоры или ...

Здравствуйте, Sergey, Вы писали:
S>IMHO, за layout отвечать должны отдельные классы, которые вообще не окна. Например так, как это сделано в wxWindows.
Хм, может быть. Можно немного поподробнее?
Моя проблема в том, что я не понимаю, как это layout может быть оторван от окна.
Вот допустим у нас есть два окна, которые сами уже окон не содержат. Мы хотим расположить их внутри родительского окна, одно слева и одно справа. При этом разделитель между ними должен вести себя как обычный сплиттер. Родительское окно мы можем считать контейнером, который вообще никакой другой функциональности не имеет, кроме как содержать в себе кого-то.
Так вот поведение сплиттера должно реализовываться именно этим контейнерным окном, т.к. только оно и получит сообщения мыши. Это означает, что окно должно быть в курсе того, какой layout используется внутри него.
С другой стороны, объект, который layout, должен как-то взаимодействовать с оконной системой, чтобы реализовывать свое поведение. Как он это будет делать, не являясь окном, мне не совсем понятно.

... << RSDN@Home 1.1 beta 2 >>

Hello, Sinclair!
You wrote on Wed, 22 Oct 2003 12:03:43 GMT:

S> Здравствуйте, Sergey, Вы писали:
S>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>> окна. Например так, как это сделано в wxWindows.
S> Хм, может быть. Можно немного поподробнее?
S> Моя проблема в том, что я не понимаю, как это layout может быть оторван
S> от окна. Вот допустим у нас есть два окна, которые сами уже окон не
S> содержат. Мы хотим расположить их внутри родительского окна, одно слева
S> и одно справа. При этом разделитель между ними должен вести себя как
S> обычный сплиттер.

Или не должен вести себя как обычный сплиттер, или вовсе разделителя никакого быть не должно — просто контролы в диалоге при ресайзе должны определенным образом менять свои размеры.

S> Родительское окно мы можем считать контейнером,
S> который вообще никакой другой функциональности не имеет, кроме как
S> содержать в себе кого-то. Так вот поведение сплиттера должно
S> реализовываться именно этим контейнерным окном, т.к. только оно и
S> получит сообщения мыши.

Сплиттер может быть окном и сам получать сообщения мыши, может быть окном и отдавать сообщений родителю, может вообще не быть самостоятельным окном (но выглядеть точно так же) и отрисовываться контейнером. (первый и последний варианты я когда-то делал руками

)

S> Это означает, что окно должно быть в курсе того,
S> какой layout используется внутри него.

Конечно. В wxWindows у него мембер такой есть — m_windowSizer. А вот что это за сайзер, оно знать не должно. Что обеспечивает большую гибкость и расширяемость.

S> С другой стороны, объект, который
S> layout, должен как-то взаимодействовать с оконной системой, чтобы
S> реализовывать свое поведение. Как он это будет делать, не являясь окном,
S> мне не совсем понятно.

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

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

Hello, zaiats_2k!
You wrote on Wed, 22 Oct 2003 11:57:46 GMT:

S>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>> окна. Например так, как это сделано в wxWindows.

zk> Я только одного не понимаю, кто мешает вам изобрести порох
zk> непромокаемый!? Ну сядьте и напишите, раз вас так эта проблема волнует!

Написано уже. Но не для Delphi.

zk> А мы потом посмотрим что лучше, анкоры или ...

Валяй, сравнивай.

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

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

S>Hello, zaiats_2k!
S>You wrote on Wed, 22 Oct 2003 11:57:46 GMT:

S>>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>>> окна. Например так, как это сделано в wxWindows.

zk>> Я только одного не понимаю, кто мешает вам изобрести порох
zk>> непромокаемый!? Ну сядьте и напишите, раз вас так эта проблема волнует!

S>Написано уже. Но не для Delphi.

Кем, когда, для чего, где взять, сколько стоит, как называется?

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

S>Hello, Sinclair!
S>You wrote on Wed, 22 Oct 2003 12:03:43 GMT:

S>> Здравствуйте, Sergey, Вы писали:
S>>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>>> окна. Например так, как это сделано в wxWindows.
S>> Хм, может быть. Можно немного поподробнее?
S>> Моя проблема в том, что я не понимаю, как это layout может быть оторван
S>> от окна. Вот допустим у нас есть два окна, которые сами уже окон не
S>> содержат. Мы хотим расположить их внутри родительского окна, одно слева
S>> и одно справа. При этом разделитель между ними должен вести себя как
S>> обычный сплиттер.

S>Или не должен вести себя как обычный сплиттер,
В каком это смысле? Я хочу дать пользователю возможность управлять не только общим размером контейнера, но и взаимными размерами его элементов.
S>или вовсе разделителя никакого быть не должно — просто контролы в диалоге при ресайзе должны определенным образом менять свои размеры.
Не согласен. Одного ресайза недостаточно.

S>Сплиттер может быть окном и сам получать сообщения мыши,
Получаем VCL. Сплиттер — не самостоятельный объект. Он всего лишь "ручка" к функциональности Layout Manager.
S>может быть окном и отдавать сообщений родителю,
А родитель что будет с ними делать?
S>может вообще не быть самостоятельным окном (но выглядеть точно так же) и отрисовываться контейнером.
Ну вот что-то типа этого я себе и представляю. Но при этом контейнер обязан знать о том, что за layout у него внутри.
S>Конечно. В wxWindows у него мембер такой есть — m_windowSizer. А вот что это за сайзер, оно знать не должно. Что обеспечивает большую гибкость и расширяемость.
Интересно, и какую функциональность на себя берет этот Sizer?
S>Посылать сообщения окнам, например. Или напрямую вызывать методы классов, реализующих окна. (что по сути одно и то же). Смысл в том, чтобы это был отдельный объект, который можно менять независимо от окон — тогда реализовать любой нужный пользователю вариант лэйаута можно не ломая существующего кода.
Это-то понятно. Вопрос в том, как он сам будет получать сообщения? У нас получается некоторое противоречие, т.к. сам набор сообщений, которые мы собираемся послать этому нашему виртуальному мемберу, зависит от того, какого он типа.

... << RSDN@Home 1.1 beta 2 >>

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

S>Написано уже. Но не для Delphi.

Уж не про джавовский ли ты говоришь?

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

S>Здравствуйте, Igor Trofimov, Вы писали:
S>

S>Нет уж увольте. к IDispatch это не имеет никакого отношения. Я бы простил, если бы они так обходились с переменными типа IDispatch. Но когда компилируется вот такой код:
S>var
S>  A: variant;
S>begin
S>  A:= 5;
S>    A.LateBoundCall(SomeValue).OtherCall;
S>end;
S>

S>я считаю это преступлением.

Просто для variant действуют неявные преобразования типов (которые, кстати, любят в C++).

Тогда уж не меньшим преступлением можно считать и следующий код:

var
  A: variant;
  B : integer;
begin
  A:= '3.5';
  B := A;
end;

Тут еще и от локали зависит. Так что ошибку тоже можно не сразу найти.
Если DecimalSeparator='.', то все хорошо, а иначе ... ошибка конвертации строки в булевский тип !
Просто это нужно знать и не допускать таких ошибок.
Variant — это разумное послабление строгих правил языка во избежание работы руками.
Разумеется, руки не должны впереди головы бежать.

Hello, Sinclair!
You wrote on Wed, 22 Oct 2003 12:33:43 GMT:

S>> Или не должен вести себя как обычный сплиттер,
S> В каком это смысле? Я хочу дать пользователю возможность управлять не
S> только общим размером контейнера, но и взаимными размерами его
S> элементов.

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

. Еще вопрос, что требуется чаще — сплиттеры или такие вот неуправляемые пользователем сайзеры.
Желательно, что бы библиотека поддерживала оба случая.
Кстати, сплиттеры в wxWindows сделаны не на основе сайзеров. IMHO, зря — хотя есть аргументы и в пользу именно такого решения.

S>> или вовсе разделителя никакого быть не должно — просто контролы в
S>> диалоге при ресайзе должны определенным образом менять свои размеры.
S> Не согласен. Одного ресайза недостаточно.

Разумеется. Я привел лишь один частный случай.

S>> может быть окном и отдавать сообщений родителю,
S> А родитель что будет с ними делать?

Ресайзить детишек, вестимо, и менять положение сплиттера.

S>> может вообще не быть самостоятельным окном (но выглядеть точно так же)
S>> и отрисовываться контейнером.
S> Ну вот что-то типа этого я себе и представляю. Но при этом контейнер
S> обязан знать о том, что за layout у него внутри.

Ну, тут есть куча вариантов. Например, произвольное количество view одного окна или ровно два дочерних окна или произвольное количество дочерних сайзеров. В случае с сайзером — сайзер умеет сообщать о своих минимальных размерах и выполнять лэйаут того, что у него внутри. Как именно он это делает, окно-контейнер знать не должно. Этого вполне достаточн для некоторых видов контейнеров. Обычное окно умеет то же самое, но его, например, проблематично уничтожать, не уничтожив его дочерние окна.

S>> Конечно. В wxWindows у него мембер такой есть — m_windowSizer. А вот
S>> что это за сайзер, оно знать не должно. Что обеспечивает большую
S>> гибкость и расширяемость.
S> Интересно, и какую функциональность на себя берет этот Sizer?

Размеры окошек, ему принадлежащих менять и информировать о своих текущих и предельных размерах, само собой. Большего от него и не требуется.

S> Это-то понятно. Вопрос в том, как он сам будет получать сообщения?

Его методы будет вызывать оконный класс — он должен знать о существовании сайзера. Просто декомпозиция на два объекта. Грубо говоря, обработчики нескольких оконных сообщений вынесли в отдельный класс.

S> У нас
S> получается некоторое противоречие, т.к. сам набор сообщений, которые мы
S> собираемся послать этому нашему виртуальному мемберу, зависит от того,
S> какого он типа.

Не вижу никакого противоречия. В принципе, для общего интерфейса сайзера вполне хватает функциональности обычного окна (WM_SIZE, WM_GETMINMAXINFO и т.п.) — просто не удобно использовать окна там где они не нужны (где можно обойтись более легковесными объектами).

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

Hello, zaiats_2k!
You wrote on Wed, 22 Oct 2003 12:32:48 GMT:

S>>>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>>>> окна. Например так, как это сделано в wxWindows.

zk>>> Я только одного не понимаю, кто мешает вам изобрести порох
zk>>> непромокаемый!? Ну сядьте и напишите, раз вас так эта проблема
zk>>> волнует!

S>> Написано уже. Но не для Delphi.

zk> Кем, когда, для чего, где взять, сколько стоит, как называется?

Называется, как я уже говорил, wxWindows, брать на www.wxwindows.org, на остальные вопросы сам ответы найдешь — если оно тебе надо.

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

Hello, Lloyd!
You wrote on Wed, 22 Oct 2003 12:44:16 GMT:

S>> Написано уже. Но не для Delphi.

L> Уж не про джавовский ли ты говоришь?

Плюсовый. Но на джавовский, AFAIK, сильно похож.

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.7 "Bedlam"

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

S>>>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>>>> окна. Например так, как это сделано в wxWindows.
_>Кем, когда, для чего, где взять, сколько стоит, как называется?
Тебе уже сказали. Воспользуйся google'ом. А вобще это кроссплатформенная ГУИ библиотека для С++.

... << RSDN@Home 1.1 beta 2 >>

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

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

S>>>>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>>>>> окна. Например так, как это сделано в wxWindows.
_>>Кем, когда, для чего, где взять, сколько стоит, как называется?
WH>Тебе уже сказали. Воспользуйся google'ом. А вобще это кроссплатформенная ГУИ библиотека для С++.

VC 6.0 я не готов ради него юзать, а 7й в списке поддерживаемых отсутствует... ;(

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

S>Не вижу никакого противоречия. В принципе, для общего интерфейса сайзера вполне хватает функциональности обычного окна (WM_SIZE, WM_GETMINMAXINFO и т.п.) — просто не удобно использовать окна там где они не нужны (где можно обойтись более легковесными объектами).
А-а. Просто когда я вижу что-то, что выглядит как окно и ведет себя как окно, я говорю "это-окно". Даже если у него нету хэндла

S>Best regards,
S> Sergey.

... << RSDN@Home 1.1 beta 2 >>

Hello, Sinclair!
You wrote on Wed, 22 Oct 2003 14:13:41 GMT:

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

S>> Не вижу никакого противоречия. В принципе, для общего интерфейса
S>> сайзера вполне хватает функциональности обычного окна (WM_SIZE,
S>> WM_GETMINMAXINFO и т.п.) — просто не удобно использовать окна там где
S>> они не нужны (где можно обойтись более легковесными объектами).
S> А-а. Просто когда я вижу что-то, что выглядит как окно и ведет себя как
S> окно, я говорю "это-окно". Даже если у него нету хэндла

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

Best regards,
Sergey.

Posted via RSDN NNTP Server 1.8 beta

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

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

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

S>>>>>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>>>>>> окна. Например так, как это сделано в wxWindows.
_>>>Кем, когда, для чего, где взять, сколько стоит, как называется?
WH>>Тебе уже сказали. Воспользуйся google'ом. А вобще это кроссплатформенная ГУИ библиотека для С++.

_>VC 6.0 я не готов ради него юзать, а 7й в списке поддерживаемых отсутствует... ;(

Можно попробовать C++BuilderX — она туда прикручена.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, zaiats_2k, Вы писали:
WC>>>Что ж делать, если Delphi специально предназначен для написания крутых GUI-программ?

Z2>>Примеры в студию! Назовите 5 крутых GUI программ написанных на Delphi?
А>Посмотри Магнат-софт! Система автоматизации производства:
А>1 — работает на 500 рабочих мест.
А>2 — 13 немецких заводов работают именно под ней.
А>Имеет внутренний макро язык. ну и т.д.
А>Dmitriy

А вы знаете, что ИНФИН (основной конкурент 1С) — написан на Delphi. Нет? Ну, тогда знайте же. Работает по всей россии и у нас на предприятии в частности на 32-компьютерных местах.

_silent

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

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

S>>По-вашему, чем вызвано такое негативное отношение?

DG>Это вызвано тем, что большинство Delphi-программистов (VBasic-программистов тоже) имеют очень низкую квалификацию.
Потому, что для того что бы начать писать Дельфях или ВБ, много знаний не требуется, по ставнению с ВС.
Низкая квалификация складывается из доступности(цена диска с Дельфёй на базаре + какая нибудь книжка) = """"программист"""".

<< silent >>

Здравствуйте, Vyacheslav A. Sartin, Вы писали:

S>>>По-вашему, чем вызвано такое негативное отношение?

DG>>Это вызвано тем, что большинство Delphi-программистов (VBasic-программистов тоже) имеют очень низкую квалификацию.
VAS>Потому, что для того что бы начать писать Дельфях или ВБ, много знаний не требуется, по ставнению с ВС.
VAS>Низкая квалификация складывается из доступности(цена диска с Дельфёй на базаре + какая нибудь книжка) = """"программист"""".

Забавный миф.

Представьте, два человека начали с нуля осваивать Delphi и ВСВ и каждый сделал простенькую программку.
На выходе получились две одинаковые программы и два человека, с "разной" квалификацией.
Квалификация у ВСВ-шника — "выше". Так? Из чего будут складываться умения этих двух программистов на этом этапе?
Из знаний
1) Языков: OP,C++
2) Библиотек: VCL ну и пусть немного ADO.
3) Зачатков алгоритмов.

Выкинем за скобки общее, что остаётся? Различие в языках.

Другой пример:
Две группы начали с нуля и сотворили два аналогичных больших и сложных проекта.
В результате, "квалификация" ВСВ-шников по-прежнему "выше"?
Если убрать за скобки общие необходимые знания и умения, необходимые для создания таких проектов,
в чём будут различия? В знании языков программирования.

Т.е. "квалификация выше" означет, что программисты на ВСВ — знают С++, а работающие на Delphi — нет?
Ну, с таким определением можно согласится, если оно будет использоваться только в указанном смысле.

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

M>Забавный миф.
Увы, это не миф.

M>Представьте, два человека начали с нуля осваивать Delphi и ВСВ и каждый сделал простенькую программку.
BCB — то же самое, что и дельфи, только немного с другим синтаксисом. Возьми хотя бы MSVC. Убогий MFC заставит поковыряться в исходниках, чтобы понять, как он работает, и в WinAPI, чтобы обойти ограничения.
M>На выходе получились две одинаковые программы и два человека, с "разной" квалификацией.
Естественно. А если бы кто-то отколбасил эту же простенькую программу на асме, то его квалификация (в кодерском смысле) будет неизмеримо выше, чем у MSVC девлопера. Потому, что кроме WinAPI придется еще и поизучать Intel, модели памяти, и подучить алгоритмы. Там, где на Delphi пишем Strings.Sorted:= True, на асме надо знать, что такое сортинг.
M>Т.е. "квалификация выше" означет, что программисты на ВСВ — знают С++, а работающие на Delphi — нет?
Да. Для BCB/Delphi это именно так. Но никто BCB с Delphi сравнивать и не берется.
Смысл в том, что любая среда, предлагающая "низкий" старт неизбежно провоцирует низкую квалификацию. Все. Точка. Когда для программирвания надо было прокалывать дырочки в перфокартах, человек, написавший Hello World был готов к написанию и значительно более сложных вещей.

Можно сравнить это с приготовлением еды супротив открывания консервов.
Если мы даем человеку возможность при приготовлении еды вскрыть банку или разогреть блины в микроволновке, то можно легко получить целую армию "поваров". И фаст-фуды именно это и делают. Но очень немногие из этих поваров задумаются над тем, откуда берутся блины и банки. И это ограничение их квалификации. Дело не в том, что они беспомощны без блинов и банок. Дело в том, что в некоторых случаях блинов и банок недостаточно. И если поварское мышление ограничено содержимым холодильника, то он всемерно будет избегать каких-либо новых решений. Просто потому, что он никогда их не делал. В клинических случаях он будет бояться посолить блюдо, потому что все, что он до сих пор "готовил", было магически посолено до него.

... << RSDN@Home 1.1.0 stable >>

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

M>Здравствуйте, Vyacheslav A. Sartin, Вы писали:

S>>>>По-вашему, чем вызвано такое негативное отношение?

DG>>>Это вызвано тем, что большинство Delphi-программистов (VBasic-программистов тоже) имеют очень низкую квалификацию.
VAS>>Потому, что для того что бы начать писать Дельфях или ВБ, много знаний не требуется, по ставнению с ВС.
VAS>>Низкая квалификация складывается из доступности(цена диска с Дельфёй на базаре + какая нибудь книжка) = """"программист"""".

M>Забавный миф.

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

M>На выходе получились две одинаковые программы и два человека, с "разной" квалификацией.
M>Квалификация у ВСВ-шника — "выше". Так?
Да, так как C++ более сложен для восприятия, посравнению с ОР.

M>Из чего будут складываться умения этих двух программистов на этом этапе?
M>Из знаний
M>1) Языков: OP,C++
M>2) Библиотек: VCL ну и пусть немного ADO.
для простенькой программы понимания VCL не требуется, может только самую малость.

M>3) Зачатков алгоритмов.
И что, теперь можно гордо кричать Я ПРОГРАММИСТ?

M>Выкинем за скобки общее, что остаётся? Различие в языках.
Это не мало важно, так как в MSDN все описания функций и тогоже ADO приведены в С-шной натации, а большинство примеров написаны на С++.
А без умения читать MSDN далеко не уйдёшь.

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

M>Т.е. "квалификация выше" означет, что программисты на ВСВ — знают С++, а работающие на Delphi — нет?
M>Ну, с таким определением можно согласится, если оно будет использоваться только в указанном смысле.

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

PS: Сам пишу на дельфях и очень от них тащюсь

, при этом наравится писать чистом асм'е. В С++ не нравится синтаксис, но без него не куда.

PSS: не кого не хотел обидить, если когото обидел извените.

<< silent >>

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

M>>Забавный миф.
S>Увы, это не миф.

M>>Представьте, два человека начали с нуля осваивать Delphi и ВСВ и каждый сделал простенькую программку.
S>BCB — то же самое, что и дельфи, только немного с другим синтаксисом. Возьми хотя бы MSVC. Убогий MFC заставит поковыряться в исходниках, чтобы понять, как он работает, и в WinAPI, чтобы обойти ограничения.
M>>На выходе получились две одинаковые программы и два человека, с "разной" квалификацией.
S>Естественно. А если бы кто-то отколбасил эту же простенькую программу на асме, то его квалификация (в кодерском смысле) будет неизмеримо выше, чем у MSVC девлопера. Потому, что кроме WinAPI придется еще и поизучать Intel, модели памяти, и подучить алгоритмы. Там, где на Delphi пишем Strings.Sorted:= True, на асме надо знать, что такое сортинг.
M>>Т.е. "квалификация выше" означет, что программисты на ВСВ — знают С++, а работающие на Delphi — нет?
S>Да. Для BCB/Delphi это именно так. Но никто BCB с Delphi сравнивать и не берется.
S>Смысл в том, что любая среда, предлагающая "низкий" старт неизбежно провоцирует низкую квалификацию. Все. Точка. Когда для программирвания надо было прокалывать дырочки в перфокартах, человек, написавший Hello World был готов к написанию и значительно более сложных вещей.

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

Аналогия понятна и принята.

<off>
Следуя ей, получается, что "эксклюзивный" повар в дорогом ресторане, имеющий в своём распоряжении обученный штат помошников, пользующийся посудой за $5000, а не за $3, и т.п., — в "кодерском" смысле неизмеримо ниже, чем первобытный человек с каменным ножом, поджаривающий на костре мамонта, которого сам перед этим и убил?

И единственный способ у такого повара повысить свою квалификацию — это перебраться в тайгу?

А для программиста С++ — перейти исключительно на ассемблер?

Другой пример:
В определённой конфигурации 1С надо чуть изменить алгоритм проводки определённого документа. Что сделает "малоквалифицированный" программист? Он изменит/добавит пару строчек в конфигурацию. И всё. А "высококвалифицированный"? Сваяет на VC+ATL ActiveX объект, реализует в нём трубеумую функциональность и вызовет этот объект из нужного места? Правильно?

<on>

А если серьёзно, я согласен с тем, что квалификация С++-ника выше дельфиста. Но только (удачный термин!) в кодерском смысле.

"Смысл в том, что любая среда, предлагающая "низкий" старт неизбежно провоцирует низкую квалификацию. Все. Точка. Когда для программирвания надо было прокалывать дырочки в перфокартах, человек, написавший Hello World был готов к написанию и значительно более сложных вещей."

Вот именно — прокалывание — кодирование. Не всякий сможет/возьмётся. А вот насчёт "готов к написанию и значительно более сложных вещей" — не обязательно. Можно так и остаться прокалывателем дырочек.

Здравствуйте, Vyacheslav A. Sartin, Вы писали:

S>>>>>По-вашему, чем вызвано такое негативное отношение?

DG>>>>Это вызвано тем, что большинство Delphi-программистов (VBasic-программистов тоже) имеют очень низкую квалификацию.
VAS>>>Потому, что для того что бы начать писать Дельфях или ВБ, много знаний не требуется, по ставнению с ВС.
VAS>>>Низкая квалификация складывается из доступности(цена диска с Дельфёй на базаре + какая нибудь книжка) = """"программист"""".

M>>Забавный миф.

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

Несколь странно. Как мне кажется, различие ВСВ и VC — только в IDE и используемых библиотеках.

M>>На выходе получились две одинаковые программы и два человека, с "разной" квалификацией.
M>>Квалификация у ВСВ-шника — "выше". Так?
VAS>Да, так как C++ более сложен для восприятия, посравнению с ОР.

Есть ещё более сложные для восприятия языки. Форт, например.

M>>Из чего будут складываться умения этих двух программистов на этом этапе?
M>>Из знаний
M>>1) Языков: OP,C++
M>>2) Библиотек: VCL ну и пусть немного ADO.
VAS>для простенькой программы понимания VCL не требуется, может только самую малость.

M>>3) Зачатков алгоритмов.
VAS>И что, теперь можно гордо кричать Я ПРОГРАММИСТ?

Точно также может кричать начинающий ВСВ-шник. Поэтому, имхо, претензии должны быть к людЯм, а не к ЯП.

M>>Выкинем за скобки общее, что остаётся? Различие в языках.
VAS>Это не мало важно, так как в MSDN все описания функций и тогоже ADO приведены в С-шной натации, а большинство примеров написаны на С++.
VAS>А без умения читать MSDN далеко не уйдёшь.

Умение/неумение читать MSDN — имхо, не зависит от языка программирования.

M>>Другой пример:
M>>Две группы начали с нуля и сотворили два аналогичных больших и сложных проекта.
M>>В результате, "квалификация" ВСВ-шников по-прежнему "выше"?
M>>Если убрать за скобки общие необходимые знания и умения, необходимые для создания таких проектов,
M>>в чём будут различия? В знании языков программирования.
VAS>Данный пример мне кажется не уместным, поскольку я писал именно про начинающих.

Согласен. Я просто хотел продемонстрировать частный случай.

M>>Т.е. "квалификация выше" означет, что программисты на ВСВ — знают С++, а работающие на Delphi — нет?
M>>Ну, с таким определением можно согласится, если оно будет использоваться только в указанном смысле.

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

VAS>PS: Сам пишу на дельфях и очень от них тащюсь

, при этом наравится писать чистом асм'е. В С++ не нравится синтаксис, но без него не куда.

Собственно, полагаю, что наши мнения сходятся.
А по-поводу исходного вопроса, думаю, правильно будет так:
Из-за более "низкого старта" в Delphi — программистов на нём — больше.
Соответсвенно, низкоквалифицированных — тоже больше.
И, следовательно, встречаются они чаще.
А?

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

M>>Представьте, два человека начали с нуля осваивать Delphi и ВСВ и каждый сделал простенькую программку.
S>BCB — то же самое, что и дельфи, только немного с другим синтаксисом. Возьми хотя бы MSVC. Убогий MFC заставит поковыряться в исходниках, чтобы понять, как он работает, и в WinAPI, чтобы обойти ограничения.
M>>На выходе получились две одинаковые программы и два человека, с "разной" квалификацией.
S>Естественно. А если бы кто-то отколбасил эту же простенькую программу на асме, то его квалификация (в кодерском смысле) будет неизмеримо выше, чем у MSVC девлопера. Потому, что кроме WinAPI придется еще и поизучать Intel, модели памяти, и подучить алгоритмы. Там, где на Delphi пишем Strings.Sorted:= True, на асме надо знать, что такое сортинг.

Да все-то верно...
Я вот только понять никак не могу, почему профессионалы, считают сложность C++, MFC, WinAPI достоинством? Допустим такая сложность заставит начинающего программиста разобраться во многих нюансах, но почему я должен снова и снова сталкиваться с этой сложностью, когда мне необходимо в сжатые сроки разработать некоторую программу?
XXI век на дворе, а я должен тратить время на написание алгоритма сортировки, потому что это повысит мою квалификацию?
Профессионал обязан иметь в своем распоряжении удобный инструмент, позволяющий быстро и качественно решить поставленную задачу.

M>>Т.е. "квалификация выше" означет, что программисты на ВСВ — знают С++, а работающие на Delphi — нет?
S>Да. Для BCB/Delphi это именно так. Но никто BCB с Delphi сравнивать и не берется.
S>Смысл в том, что любая среда, предлагающая "низкий" старт неизбежно провоцирует низкую квалификацию. Все. Точка. Когда для программирвания надо было прокалывать дырочки в перфокартах, человек, написавший Hello World был готов к написанию и значительно более сложных вещей.

Опять-таки верно, Delphi допускает низкий старт. Но давайте не перекладывать с больной головы на здоровую. Никто не мешает повышать свою квалификацию, программируя на том же Delphi, только теперь это становится необязательно. А настоящие профессионалы, уж будьте уверены, знают и про модели памяти, и про алгоритмы сортировки и не только про это. Язык программирования тут ни при чем.

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

K_O>Да все-то верно...
K_O>Я вот только понять никак не могу, почему профессионалы, считают сложность C++, MFC, WinAPI достоинством? Допустим такая сложность заставит начинающего программиста разобраться во многих нюансах, но почему я должен снова и снова сталкиваться с этой сложностью, когда мне необходимо в сжатые сроки разработать некоторую программу?
K_O>XXI век на дворе, а я должен тратить время на написание алгоритма сортировки, потому что это повысит мою квалификацию?
K_O>Профессионал обязан иметь в своем распоряжении удобный инструмент, позволяющий быстро и качественно решить поставленную задачу.

Наш выбор — VC++ 7.1! Вся мощь С++ при поддержке WinForms!

Если есть что-то позвляющее решить задачу или быстрее или качественнее — покажите мне это!

РМ>Кроме того дельфи провоцирует знать как можно меньше.

Ну и сказанул. Операционная система,WinApi,С++ тоже провоцирует знать как можно меньше. Они скрывают от тебя комманды процессора, знания железа, например каждую видео и звуковую карты в отдельности .

Просто Делфи еще более навороченная среда чем голый API. Весь Api завернут в классы. И это есть правильно, т.к. знания констант и методов создания окна на WInAPI становяться ненужными когда есть класс обертка TForm. Создать окно на WinAPI ничем не умнее чем создать окно на Делфи. Но геморойнее.

> Есть ещё более сложные для восприятия языки. Форт, например.

Все дело в привычки. Сам на нем один раз попробовал и не понравилось. Однако у меня отец от него тащится

> VAS>Это не мало важно, так как в MSDN все описания функций и тогоже ADO приведены в С-шной натации, а большинство примеров написаны на С++.
> VAS>А без умения читать MSDN далеко не уйдёшь.
>
> Умение/неумение читать MSDN — имхо, не зависит от языка программирования.

А зависит от количества языков, которыми владеешь! Шутка. Просто, чтобы читать msdn нужно немного знать английский язык, а по синтаксису языка (даже если его не знаешь) можно догадаться, что там происходит (правда, не всегда).

А, вообще, я с тобой согласен. Delphi — простой способ создания ПО (в принципе любой сложности).

Posted via RSDN NNTP Server 1.7 "Bedlam"

_>Наш выбор — VC++ 7.1! Вся мощь С++ при поддержке WinForms!

_>Если есть что-то позвляющее решить задачу или быстрее или качественнее — покажите мне это!

Да ты и сам догадываешься. На C# писать быстрее.

... << RSDN@Home 1.1.0 stable >>

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

РМ>>Кроме того дельфи провоцирует знать как можно меньше.
КВБ>Ну и сказанул. Операционная система,WinApi,С++ тоже провоцирует знать как можно меньше. Они скрывают от тебя комманды процессора, знания железа, например каждую видео и звуковую карты в отдельности .
Но знание команд процессора, умение программировать на ассемблере помогает лучше программировать на С++. Это очевидно.

КВБ>Просто Делфи еще более навороченная среда чем голый API. Весь Api завернут в классы. И это есть правильно, т.к. знания констант и методов создания окна на WInAPI становяться ненужными когда есть класс обертка TForm. Создать окно на WinAPI ничем не умнее чем создать окно на Делфи. Но геморойнее.
Ну насчет гемморойнее — это не правда. Что так пять минут, что эдак. А с приличной библиотекой, так и быстрее, чем на дельфи, и без мышки. Мне лично больше нравится клавиатурой щелкать, чем мышкой дергать, так как в первом случае результат у меня перед глазами, я могу его очевидным образом поправить, переделать и даже отменить совсем, а мышкой подергал, что-то там за кулисами дернулось, а что — не понятно. То есть знатоки конечно знают, но и то не все. Дело вкуса.

... << RSDN@Home 1.1.0 stable >>

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

РМ>Здравствуйте, Колобок В бане, Вы писали:

РМ>>>Кроме того дельфи провоцирует знать как можно меньше.
КВБ>>Ну и сказанул. Операционная система,WinApi,С++ тоже провоцирует знать как можно меньше. Они скрывают от тебя комманды процессора, знания железа, например каждую видео и звуковую карты в отдельности .
РМ>Но знание команд процессора, умение программировать на ассемблере помогает лучше программировать на С++. Это очевидно.
Потому что ни С++, ни стандартные библиотеки не предоставляют программисту достаточного минимума функциональности, которой к тому же было бы просто пользоваться. Вот и приходится очень многое писать руками.

КВБ>>Просто Делфи еще более навороченная среда чем голый API. Весь Api завернут в классы. И это есть правильно, т.к. знания констант и методов создания окна на WInAPI становяться ненужными когда есть класс обертка TForm. Создать окно на WinAPI ничем не умнее чем создать окно на Делфи. Но геморойнее.
РМ>Ну насчет гемморойнее — это не правда. Что так пять минут, что эдак. А с приличной библиотекой, так и быстрее, чем на дельфи, и без мышки. Мне лично больше нравится клавиатурой щелкать, чем мышкой дергать, так как в первом случае результат у меня перед глазами,
Если я правильно понял, у тебя перед глазами исходный код, а не вид окна. А для программирования GUI второе соврешенно необходимо.
В Delphi мне не надо сидеть пятнадцать минут, ожидая пока соберется проект, лишь для того чтобы увидеть, что вот такой-то контрол надо передвинуть на 3 пикселя влево.

РМ>я могу его очевидным образом поправить, переделать и даже отменить совсем, а мышкой подергал, что-то там за кулисами дернулось, а что — не понятно. То есть знатоки конечно знают, но и то не все. Дело вкуса.
А редактирование кода, сгенерированного автоматически еще никто не отменял. Более того, ты можешь сам в исходнике добавить контролы на форму (+ внести изменения в DFM файл) и это отразится в Дизайнере Формы. Просто это оказывается ненужным.

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

РМ>>Но знание команд процессора, умение программировать на ассемблере помогает лучше программировать на С++. Это очевидно.
K_O>Потому что ни С++, ни стандартные библиотеки не предоставляют программисту достаточного минимума функциональности, которой к тому же было бы просто пользоваться. Вот и приходится очень многое писать руками.
И поэтому тоже, но я имел ввиду гораздо другую вещь. А именно понимание того, что происходит внутри, всегда помогает понимать, как пользоваться тем, что снаружи. Я считаю, что программист СОВСЕМ не умеющий писать на ассемблере — не может писать ничего путного, если задача чуть сложнее хелло ворлд.

КВБ>>>Просто Делфи еще более навороченная среда чем голый API. Весь Api завернут в классы. И это есть правильно, т.к. знания констант и методов создания окна на WInAPI становяться ненужными когда есть класс обертка TForm. Создать окно на WinAPI ничем не умнее чем создать окно на Делфи. Но геморойнее.
РМ>>Ну насчет гемморойнее — это не правда. Что так пять минут, что эдак. А с приличной библиотекой, так и быстрее, чем на дельфи, и без мышки. Мне лично больше нравится клавиатурой щелкать, чем мышкой дергать, так как в первом случае результат у меня перед глазами,
K_O>Если я правильно понял, у тебя перед глазами исходный код, а не вид окна.

K_O>А для программирования GUI второе соврешенно необходимо.
Я в этом не уверен. Это зависит от того, как ты подходишь к его созданию. Мне гораздо ближе не городить всяких сложностей, а сделать как можно проще. Плюс хорошая библиотека помогает очевидным способом организовать всякие сплиттеры.

K_O>В Delphi мне не надо сидеть пятнадцать минут, ожидая пока соберется проект, лишь для того чтобы увидеть, что вот такой-то контрол надо передвинуть на 3 пикселя влево.
Слабо представляю себе ситуацию, когда контрол надо двигать на 3 пикселя влево. То есть совсем не представляю.
Мне кажется, что положение контролов должно определяться получавтоматически, т.е. ты указваешь: вот editbox, вот текст статика к нему, статик пусть будет слева ( или сверху, а больше и не бывает разумных положений ).

РМ>>я могу его очевидным образом поправить, переделать и даже отменить совсем, а мышкой подергал, что-то там за кулисами дернулось, а что — не понятно. То есть знатоки конечно знают, но и то не все. Дело вкуса.
K_O>А редактирование кода, сгенерированного автоматически еще никто не отменял.
Автоматически сгенеренный код — это просто роспись разработчиков библиотеки в том, что они не смогли сделать нормальную библиотеку. К MFC это относится в очень большой степени, в дельфи с этим немного лучше. Так вот, моя идея в том, что с нормальной библиотекой, кода для написания обработчика события надо писать так мало, что мастера вызывать будет в сто раз дольше. Нормальная библиотека, это например модифицированная и доработанная SWL.
Другая моя идея в том, что то, что мастером создано, мастером же должно быть возможно и подредактировать и убрать и т.д. В дельфи с этим кстати не так плохо. А в MFC просто ужасно.
Но тем не менее, меня лично в дельфи дико раздражает, что огромная часть программы существует не в виде исходных текстов, а ввиде всяких настроечек и настроек всяких проперти. Разбираться в незнакомой программе, использующей незнакомые контролы получается — сущий ад.

Да, я совсем не хочу наехать на дельфи, дельфистов, MFC, MFC'истов и вообще кого бы то ни было. Но лично я не считаю это действительно удобными инструментами. Это инструменты, которые просты для новичков, направленные не на эффективность разработки, а на скорость освоения. У меня другие предпочтения.

... << RSDN@Home 1.1.0 stable >>

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

M>А?

Полностью поддерживаю

<< silent >>

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

РМ>Так вот, моя идея в том, что с нормальной библиотекой, кода для написания обработчика события надо писать так мало, что мастера вызывать будет в сто раз дольше. Нормальная библиотека, это например модифицированная и доработанная SWL.
Так и есть.
РМ>Другая моя идея в том, что то, что мастером создано, мастером же должно быть возможно и подредактировать и убрать и т.д. В дельфи с этим кстати не так плохо. А в MFC просто ужасно.
Согласен. Но мы в данный момент не про MFC — это вообще выдающийся пример бездарного разбазаривания денег Билли.
РМ>Но тем не менее, меня лично в дельфи дико раздражает, что огромная часть программы существует не в виде исходных текстов, а ввиде всяких настроечек и настроек всяких проперти. Разбираться в незнакомой программе, использующей незнакомые контролы получается — сущий ад.
Вот это просто от непривычки к декларативному программированию. Это противоречит твоей же первой идее, т.к. короче, чем OnCreate=FormCreate ничего не бывает. А это ровно тот код, который необходимо и достаточно написать на Delphi для привязки обработчика. Никто не заставляет тебя поднимать форм дизайнер. Пиши прямо в DFM.

... << RSDN@Home 1.1.0 stable >>

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

K_O>Да все-то верно...
K_O>Я вот только понять никак не могу, почему профессионалы, считают сложность C++, MFC, WinAPI достоинством?
Никто не считает сложность достоинством. Но неумолимый факт говорит о том, что в среду разработчиков на С++, MFC, WinAPI существует достаточно жесткий отбор. Благодаря ему туда попадают лишь сильные духом. А отсутствие барьера в Delphi впускает в программирование совершенно случайных людей. Все. Максимальный уровень разработчика никак не зависит от языка программирования. Но минимальный уровень тащит вниз и средний.

... << RSDN@Home 1.1.0 stable >>

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

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

K_O>>Да все-то верно...
K_O>>Я вот только понять никак не могу, почему профессионалы, считают сложность C++, MFC, WinAPI достоинством?
S>Никто не считает сложность достоинством. Но неумолимый факт говорит о том, что в среду разработчиков на С++, MFC, WinAPI существует достаточно жесткий отбор. Благодаря ему туда попадают лишь сильные духом. А отсутствие барьера в Delphi впускает в программирование совершенно случайных людей. Все. Максимальный уровень разработчика никак не зависит от языка программирования. Но минимальный уровень тащит вниз и средний.
Скорее, Delphi расширяет круг лиц, кому стало доступно программирование. И это есть хорошо.
А число профи от этого не уменьшилось.

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

S>Здравствуйте, Рома Мик, Вы писали:

РМ>>Другая моя идея в том, что то, что мастером создано, мастером же должно быть возможно и подредактировать и убрать и т.д. В дельфи с этим кстати не так плохо. А в MFC просто ужасно.
S>Согласен. Но мы в данный момент не про MFC — это вообще выдающийся пример бездарного разбазаривания денег Билли.
Я на самом деле не знаю ни одного радостного средства программирования где все было бы супер с этим вопросом. В дельфи, конечно, можно убрать обработчик события из карты сообщений, но сам обработчик придется удалять вручную, нельзя мастером, мышкой переназначить обработчик на другое событие и т.д. ИМХО если уж делать написание программы в ГУИ, т.е. мышкой, то надо скрывать от разработчика саму парадигму исходных текстов. Не совсем, конечно, а только чтобы ему не было нужно туда лезть. Чтобы были отдельные обработчики, которые каждый в своем окне, мышкой их туда-сюда тягать. А так приходится массу всего все равно доделывать руками, что портит впечатление. А на самом деле, если уж пошла такая пьянка, то желательно, чтобы раработчик писал руками только логику, а интерфейс навешивал полностью мышкой вообще не видя при этом генерируемых исходников.

РМ>>Но тем не менее, меня лично в дельфи дико раздражает, что огромная часть программы существует не в виде исходных текстов, а ввиде всяких настроечек и настроек всяких проперти. Разбираться в незнакомой программе, использующей незнакомые контролы получается — сущий ад.
S>Вот это просто от непривычки к декларативному программированию. Это противоречит твоей же первой идее, т.к. короче, чем OnCreate=FormCreate ничего не бывает. А это ровно тот код, который необходимо и достаточно написать на Delphi для привязки обработчика. Никто не заставляет тебя поднимать форм дизайнер. Пиши прямо в DFM.
Бывает. В моей библиотечке по мотивам SWL ( я ей пользуюсь, но еще не доделал до конца многое ) я пишу просто:
MRWL_ON( Message, ClassName, WM_CREATE )
{
...
}
Все. Никаких карт сообщений и прочего. При том, что тащу за собой минимум рантайма. И это реализовано cредствами только языка C++.

Если же взяться за дело масштабно, то есть писать всякие мастера и прочее, то можно достичь супер эффективности и удобства.

... << RSDN@Home 1.1.0 stable >>

S>>Согласен. Но мы в данный момент не про MFC — это вообще выдающийся пример бездарного разбазаривания денег Билли.
РМ>Я на самом деле не знаю ни одного радостного средства программирования где все было бы супер с этим вопросом. В дельфи, конечно, можно убрать обработчик события из карты сообщений, но сам обработчик придется удалять вручную,

Угу , а если закрыть проект, то файлы с диска тоже вручную удалять приходиться.
В VC++ тоже если удалить класс то его методы остануться.

>нельзя мастером, мышкой переназначить обработчик на другое событие и т.д.
Почему нельзя ? Можно. Если это событие совместимо ( объявление обработчиков совпадают ) иначе это теряет смысл.

>> ИМХО если уж делать написание программы в ГУИ, т.е. мышкой, то надо скрывать от разработчика саму парадигму исходных текстов. Не совсем, конечно, а только чтобы ему не было нужно туда лезть. Чтобы были отдельные обработчики, которые каждый в своем окне, мышкой их туда-сюда тягать.

Ну так ты не листай прокрутку, щелкнул по кнопке — попал в редактор события , отредактировал и выбрал другое событие и т.д. , не трогай прокрутку.

>>А так приходится массу всего все равно доделывать руками, что портит впечатление. А на самом деле, если уж пошла >>такая пьянка, то желательно, чтобы раработчик писал руками только логику, а интерфейс навешивал полностью мышкой >>вообще не видя при этом генерируемых исходников.

А чем это не делфи ? Руками логика пишется а интерфес мышкой царапается.

РМ>>>Но тем не менее, меня лично в дельфи дико раздражает, что огромная часть программы существует не в виде исходных текстов, а ввиде всяких настроечек и настроек всяких проперти. Разбираться в незнакомой программе, использующей незнакомые контролы получается — сущий ад.

Ну если на то пошло, при использовании сторонних библиотек в C++ тоже придется разбиратся в незнакомой программе — получается ссущий яд.
И это будет сложнее чем понять смысл какого нить Property. Объектное программирование тем и хорошо что наружу выводяться те методы которые необходимы для данного объекта и не видно страшной реализации и как правило принято именовать их понятным образом.Чтобы в названии уже был достаточный хелп. Caption, Length, Width, Heigth, для каждой сущности легко понять что это значит.
По умолчанию считается что этот черный ящик работает корректно. Вот если наблюдаются отклонения от желаемого результата тогда можно и слазать во внутренности. Когда выбираешь телик — не лезешь внуть, просто крутишь ручки , проверяещь "интерфейсы". Как правило лучше не использовать сторонних библиотек, особенно Free написанных васями,
т.к. как правило эти черные ящики очень не надежны. Тоже самое относиться и к C++ библиотекам.

РМ>Если же взяться за дело масштабно, то есть писать всякие мастера и прочее, то можно достичь супер эффективности и удобства.

Угу , и ты удивишся когда у тебя вдруг получится тот же делфи.

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

РМ>Я на самом деле не знаю ни одного радостного средства программирования где все было бы супер с этим вопросом. В дельфи, конечно, можно убрать обработчик события из карты сообщений, но сам обработчик придется удалять вручную, нельзя мастером, мышкой переназначить обработчик на другое событие и т.д. ИМХО если уж делать написание программы в ГУИ, т.е. мышкой, то надо скрывать от разработчика саму парадигму исходных текстов. Не совсем, конечно, а только чтобы ему не было нужно туда лезть.
Идея Delphi не в сокрытии исходных текстов, а в том, что еще до сборки проекта я могу видеть конечный результат.

PM>Чтобы были отдельные обработчики, которые каждый в своем окне, мышкой их туда-сюда тягать. А так приходится массу всего все равно доделывать руками, что портит впечатление. А на самом деле, если уж пошла такая пьянка, то желательно, чтобы раработчик писал руками только логику, а интерфейс навешивал полностью мышкой вообще не видя при этом генерируемых исходников.
Не выйдет. Для создания профессионального пользовательского интерфейса порой приходится прибегать к весьма нетривиальным алгоритмам. А все порой из-за того, чтобы не было какого-то малозаметного подергивания или мерцания.

РМ>>>Но тем не менее, меня лично в дельфи дико раздражает, что огромная часть программы существует не в виде исходных текстов, а ввиде всяких настроечек и настроек всяких проперти. Разбираться в незнакомой программе, использующей незнакомые контролы получается — сущий ад.
А что, было бы лучше, если бы у нас были килобайты setPropertyXXX в исходном коде? Зачем?

S>>Вот это просто от непривычки к декларативному программированию. Это противоречит твоей же первой идее, т.к. короче, чем OnCreate=FormCreate ничего не бывает. А это ровно тот код, который необходимо и достаточно написать на Delphi для привязки обработчика. Никто не заставляет тебя поднимать форм дизайнер. Пиши прямо в DFM.
РМ>Бывает. В моей библиотечке по мотивам SWL ( я ей пользуюсь, но еще не доделал до конца многое ) я пишу просто:
РМ>MRWL_ON( Message, ClassName, WM_CREATE )
РМ>{
РМ> ...
РМ>}
РМ>Все. Никаких карт сообщений и прочего. При том, что тащу за собой минимум рантайма. И это реализовано cредствами только языка C++.
Все это замечательно до тех пор, пока ты пользуешься этой библиотекой один. Потому что ты в ней все знаешь. А для меня, например, абсолютно неясно что означает заклинание MRWL_ON. Что это — макрос, функция, что он(а) делает? Из названия неясно.

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

K_O>Здравствуйте, Рома Мик, Вы писали:

РМ>>Я на самом деле не знаю ни одного радостного средства программирования где все было бы супер с этим вопросом. В дельфи, конечно, можно убрать обработчик события из карты сообщений, но сам обработчик придется удалять вручную, нельзя мастером, мышкой переназначить обработчик на другое событие и т.д. ИМХО если уж делать написание программы в ГУИ, т.е. мышкой, то надо скрывать от разработчика саму парадигму исходных текстов. Не совсем, конечно, а только чтобы ему не было нужно туда лезть.
K_O>Идея Delphi не в сокрытии исходных текстов, а в том, что еще до сборки проекта я могу видеть конечный результат.
Конечный результат можно видеть в любом редакторе ресурсов, хотя идея ресурсов мне тоже не нравится. ИМХО можно сделать интерфейс не описыая отдельно внешний вид, отдельно функционал. А сразу вместе.

K_O>А все порой из-за того, чтобы не было какого-то малозаметного подергивания или мерцания.
Мерцание должно устранятся на этапе разработки библиотеки.

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

K_O>А для меня, например, абсолютно неясно что означает заклинание MRWL_ON. Что это — макрос, функция, что он(а) делает? Из названия неясно.
Вначале было MRWL_ON_MESSAGE, потом стало MRWL_ON( Message ... ). Так как бывает еще Command и Notify. Это макрос, определяющий функцию обработчик и регистрирующий ее в карте сообщений. Таким образом, то, что это сообщение обрабатывается классом, упоминается в ОДНОМ месте, а не в двух и больше как предлагают нам другие товарищи. И удалется, пределывается интуитивно понятным образом, не надо судорожно вспоминать, что еще нужно почистить.

... << RSDN@Home 1.1.0 stable >>

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

К>Ну так ты не листай прокрутку, щелкнул по кнопке — попал в редактор события , отредактировал и выбрал другое событие и т.д. , не трогай прокрутку.
Именно от стиль, которого бы хотелось достичь. Но при условии, что не получаются при этом уродцы жуткие. Или если я ненароком неправильно назвал обработчик? Или вообще случайно не туда щелкнул? Все иддилия нарушается.

>>>А так приходится массу всего все равно доделывать руками, что портит впечатление. А на самом деле, если уж пошла >>такая пьянка, то желательно, чтобы раработчик писал руками только логику, а интерфейс навешивал полностью мышкой >>вообще не видя при этом генерируемых исходников.
К>А чем это не делфи ? Руками логика пишется а интерфес мышкой царапается.
Да в том-то и дело что интерфейс только кажется царапающимся мышкой, а на самом деле потом его еще сто раз руками перелопатишь.

РМ>>>>Но тем не менее, меня лично в дельфи дико раздражает, что огромная часть программы существует не в виде исходных текстов, а ввиде всяких настроечек и настроек всяких проперти. Разбираться в незнакомой программе, использующей незнакомые контролы получается — сущий ад.
К>Ну если на то пошло, при использовании сторонних библиотек в C++ тоже придется разбиратся в незнакомой программе — получается ссущий яд.
Зависит от сложности библиотеки.

К>Объектное программирование тем и хорошо что наружу выводяться те методы которые необходимы для данного объекта и не видно страшной реализации и как правило принято именовать их понятным образом.
Да, конечно. C++ кстати тоже объектно-ориентированный, ты не в курсе?

РМ>>Если же взяться за дело масштабно, то есть писать всякие мастера и прочее, то можно достичь супер эффективности и удобства.
К>Угу , и ты удивишся когда у тебя вдруг получится тот же делфи.
Ну уж нет. Должно хранится гораздо больше всякой информации. Или, например, исходник ГУЯ не должен быть исходником на паскале, c++ и т.д., т.к. это не позволяет грамотно отобразить всю информацию по возможности компактно.
В дельфи мы создаем кнопку. Создаем к ней обработчик того, сего. Они как-то называются, т.е. уже три независимых сущности, объединенных только шаткими установками проперти. А если я переименую один из них то все рассыпется. Уж если писать тяжелый тул, то тогда пусть кнопка в исходнике формы выглядит так:

Form MyForm "MainForm"
{
    Button MyButton "Батон"
    {
        OnClick()
        {
        }
    }
}

Чтобы все в одном месте и все связи прописны жестко без привязки к именам, чтобы их нельзя было порушить.
Тут в принципе много думать надо как правильно делать. Можно чтобы все это был не текст, а хитрое окно в котором все можно редактировать, совмещающее проперти и текстовый едитор.

А вообще, спорить ту не о чем. Мне кажется, что радостным тулам есть куда совершенствоваться, а пока они не удобны и т.д. Но это просто мне так кажется, я точно не знаю, т.к. не пользуюсь ( потому, что мне так кажется ) этим тулзами.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, Рома Мик, Вы писали:
РМ>... А если я переименую один из них то все рассыпется. Уж если писать тяжелый тул, то тогда пусть кнопка в исходнике формы выглядит так:
РМ>

РМ>Form MyForm "MainForm"
РМ>{
РМ>    Button MyButton "Батон"
РМ>    {
РМ>        OnClick()
РМ>        {
РМ>        }
РМ>    }
РМ>}
РМ>

РМ>Чтобы все в одном месте и все связи прописны жестко без привязки к именам, чтобы их нельзя было порушить.
на закладке Standart есть такой компонет — TActionList(реализует паттерн Command) , появился кажется еще в Delphi 5.
создаем отдельный датамодуль, кидаем туда этот компонет, добавляем команды ,настраиваем им хинты,caption, пиктограммы
горячие клавиши, раскладываем по категориям. пишем реализацию методов Execute

procedure TDataModule1.ActionSaveFileExecute(Sender: TObject);
begin
 ..
end;

Все в одном месте.

можно создать билиотеку стадартных команд и зарегистрировав в IDE добавлять их в ActionList, есть
около 50 готовых команд (сохранить,скопировать и тд) в различных категориях(Edit,Format,Window,Search,File,List,Dialog и тд).

затем в при создании формы пишем

procedure TForm1.FormCreate(Sender: TObject);
begin
 ButtonSave.Action:=DataModule1.SaveFile;
end;

не хотим в рантайме — делаем в дизайнере,
свойство Action есть практически у всех элеметов управления типа кнопок,толбаров итд.
Чем это отличается от MRWL_ON_MESSAGE, и тд?
Ок, идем дальше. Начиная с Delphi 6 появились фреймы(там же на Standart).
Черезвычайно удобна штука: создаем фрейм, размещаем там элементы управления, связываем их событиями
(например фрейм с dbгридом для редктирования данных,навигаторм и фильтрацией )
затем используем этот фрейм как обычный компонет, без установки его в IDE.
Хотим — вставлям его в другие формы, разделяем между разработчиками,
хотим — работаем как с обычной формой (Frame.ManualFloat())

если грамотно все построить,то ничего не рассыпается

... << RSDN@Home 1.1 beta 2 >>

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

D_T>если грамотно все построить,то ничего не рассыпается

Как я уже говорил, я совсем не в курсе последних тенденций в мире дельфи. Имел дело плотно только с дельфи 3. Значит не я один такой умный и все движется к правильному положению вещей. Урра и т.д. и т.п. Убедил, победил, заставил усомнится.
Вот разгружусь чуть-чуть и побегу смотреть на последнюю дельфи. Хотя, конечно, еще не идеал, так как тот не достижим.

... << RSDN@Home 1.1.0 stable >>

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

РМ>Бывает. В моей библиотечке по мотивам SWL ( я ей пользуюсь, но еще не доделал до конца многое ) я пишу просто:
РМ>MRWL_ON( Message, ClassName, WM_CREATE )
РМ>{
РМ> ...
РМ>}
РМ>Все. Никаких карт сообщений и прочего. При том, что тащу за собой минимум рантайма. И это реализовано cредствами только языка C++.
В Delphi ты бы написал вот так:
type ClassName = class(BaseClassName)
procedure OnCreate(Message: TMessage); message WM_CREATE;
end;

И все. Никаких карт сообщений и прочего. При том, что для этого даже VCL не требуется — только модуль system. Ну да, в паскале нет синтаксиса определения тела метода в объявлении класса. В остальном все уже сделано.

По поводу примера с кнопкой — все то же самое. Если очень хочется написать код, который гарантирован от повторного использования — пожалуйста, делаем свой класс кнопки, перегружаем WM_CLICK прямо в нем и вставляем в форму.

... << RSDN@Home 1.1 beta 2 >>

Здравствуйте, Рома Мик, Вы писали:
РМ>Конечный результат можно видеть в любом редакторе ресурсов, хотя идея ресурсов мне тоже не нравится. ИМХО можно сделать интерфейс не описыая отдельно внешний вид, отдельно функционал. А сразу вместе.
Это неправда. Покажи-ка мне редактор ресурсов, который покажет мне конечный вид формы, использующей 3rd-party контролы? А не те 10 штук, заботливо встроенные на этапе проектирования редактора ресурсов 10 лет назад?

... << RSDN@Home 1.1 beta 2 >>

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

K_O>>Идея Delphi не в сокрытии исходных текстов, а в том, что еще до сборки проекта я могу видеть конечный результат.
РМ>Конечный результат можно видеть в любом редакторе ресурсов, хотя идея ресурсов мне тоже не нравится. ИМХО можно сделать интерфейс не описыая отдельно внешний вид, отдельно функционал. А сразу вместе.

Это противоречит одной из базовых концепций дизайна программных систем — отделяй содержимое от представления. Грамотно спроектированная форма не содержит ничего, кроме кода, обеспечивающего функционирование самой формы.

... << RSDN@Home 1.1.2 beta 1 >>

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

AVK>Это противоречит одной из базовых концепций дизайна программных систем — отделяй содержимое от представления. Грамотно спроектированная форма не содержит ничего, кроме кода, обеспечивающего функционирование самой формы.
Это-то само собой. Имелось ввиду, что сейчас получается, что форма и ее функционирование описываются в разных местах, а мне кажется что все можно описать в одном месте и в виде кода.
Фактически как раз нынешнее положение вещей и ведет к нарушению указанной концепции, так как проще сразу писать код в автоматически сгенеренных функциях и этот код оказывается перемешан с кодом, ответственным за функционирование формы.

... << RSDN@Home 1.1.0 stable >>

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

РМ>Здравствуйте, AndrewVK, Вы писали:

AVK>>Это противоречит одной из базовых концепций дизайна программных систем — отделяй содержимое от представления. Грамотно спроектированная форма не содержит ничего, кроме кода, обеспечивающего функционирование самой формы.
РМ>Это-то само собой. Имелось ввиду, что сейчас получается, что форма и ее функционирование описываются в разных местах, а мне кажется что все можно описать в одном месте и в виде кода.
РМ>Фактически как раз нынешнее положение вещей и ведет к нарушению указанной концепции, так как проще сразу писать код в автоматически сгенеренных функциях и этот код оказывается перемешан с кодом, ответственным за функционирование формы.

Ну так юзай .NET, там вся информация о форме сериализуется в код.

Здравствуйте, Dr_Sh0ck

Да, да!!!! Золотые слова! Когда видишь в книге по Delphi в главе про
потоки Windows фразу типа: "потоки в Windows очень важны, но вам про них
знать не обязательно, т.к. в VCL есть класс TThread" — прямо мороз по коже
проходит! Самое ужасное, что многие мои коллеги дельфисты (сам я предпочитаю
C++) даже с многолетним стажем работы до сих пор так думают!

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

ZEN>- Delphi не умеет работать с полными состояниями объектов (сериализация как в Java), сохранение published-свойств наследников TComponent — жалкое подобие Java-сериализации — ничего кроме сохранения "внешнего" состояния, но не внутреннего не даёт;
Фигня, нам удалось. Сохранить можно все что угодно, хоть текущую дату и количество памяти, свободной в настоящий момент. Для этого достаточно полазать по базовым классам и внимательно почитать их код (Delphi 6). Пример, кстати, есть у Архангельского еще для D4, если память не изменяет.

В качестве еще одного развенчания мифа, могу сообщить о том, что у меня сейчас есть система логгирования создания/изменения объектов (на Delphi, подключается как unit), с помощью которой можно за час с тестированием написать не только сборку мусора, но и контроль утечек даже с именами объектов. При этом это заметно НЕ сказывается на скорости работы.

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

V>В качестве еще одного развенчания мифа, могу сообщить о том, что у меня сейчас есть система логгирования создания/изменения объектов (на Delphi, подключается как unit), с помощью которой можно за час с тестированием написать не только сборку мусора,

GC за час! Хочу такую траву

... << RSDN@Home 1.1.2 beta 2 (mobile station) >>

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

AVK>GC за час! Хочу такую траву

Так сделай сам. Я писал это где-то недели две не напрягаясь, точнее оценить трудно, так как были и другие задачи. Все на основе стандартного интерфейса диспетчера памяти + перехват нескольких функций.
GC для объектов/блоков памяти делать задачи как таковой не было, боролись с утечками просто.

Здравствуйте, Аноним, Вы писали:

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

S>>Часто приходится слышать мнение, что разработчики, использующие delphi -
S>>ваще не программисты, а так... детишки неразумные.
S>>Ясно, что у нее (как и у каждого ср-ва разработки) есть свои минусы,
S>>но и плюсы тоже имеются. Я, например, юзаю с равной интенсивностью и
S>>delphi, и vc++, и MASM. И что, об этом лучше никому не говорить?
S>>По-вашему, чем вызвано такое негативное отношение?
А>Мда... что-то тема совсем заглохла...

А что, кто-то ещё не знает ответа на этот вопрос? Тогда повторю — Негативное отношение к Delphi вызвано огромным количеством ламеров его юзающих, наполняющих форумы идиотскими вопросами, ответы на которые находятся за одну минуту в хелпе\интернете.
Да у Delphi есть достоинства, да ламеры программят не только на Delphi, это все признают, но тем не менее...

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

_>Наш выбор — VC++ 7.1! Вся мощь С++ при поддержке WinForms!

_>Если есть что-то позвляющее решить задачу или быстрее или качественнее — покажите мне это!

Боже мой, как низко пали сиплюсисты за два года, пока идет этот топик!

От "какие мы крутые, все врукопашную, все под контролем наших гениальных мозгов" до "VC++ 7.1+WinForms". Ну и чем это отличается от дельфей!

Здравствуйте, <Аноним>, Вы писали:

А>Боже мой, как низко пали сиплюсисты за два года, пока идет этот топик!

От "какие мы крутые, все врукопашную, все под контролем наших гениальных мозгов" до "VC++ 7.1+WinForms". Ну и чем это отличается от дельфей!

То ли еще будет ой-ой-ой.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Аноним, Вы писали:

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

_>>Наш выбор — VC++ 7.1! Вся мощь С++ при поддержке WinForms!

_>>Если есть что-то позвляющее решить задачу или быстрее или качественнее — покажите мне это!

А>Боже мой, как низко пали сиплюсисты за два года, пока идет этот топик!

От "какие мы крутые, все врукопашную, все под контролем наших гениальных мозгов" до "VC++ 7.1+WinForms". Ну и чем это отличается от дельфей!

Это была провокация! Я вообще-то старый дельфист, и на сях ничего серьёзного никогда не писал.

))

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

_>Это была провокация! Я вообще-то старый дельфист, и на сях ничего серьёзного никогда не писал.

))

Прикольно звучит, особенно если утрировать : "дельфист-пенсионер"

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

чую, с C# скоро будет тоже самое...

... << RSDN@Home 1.1.3 stable >>

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

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

R>чую, с C# скоро будет тоже самое...

История циклична

Интересно, а после шарпа что будет?

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

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

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

R>>чую, с C# скоро будет тоже самое...

К>История циклична

К>Интересно, а после шарпа что будет?

Да плюсы и будут, RAD нормальный майкрософт к нему прикрутила, так что всё — ДЕРЖИТЕ МЕНЯ СЕМЕРО!

))

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

_>Да плюсы и будут, RAD нормальный майкрософт к нему прикрутила, так что всё — ДЕРЖИТЕ МЕНЯ СЕМЕРО!

))
Да уж! Не прошло и десяти лет

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

DM>>В определенных вещах ДА! Я имею ввиду конечно же не всех. Просто человек никогда не писавший на API, а только на MFC знает о "окнах" значительно меньше, чем API программера.
H_D>Ох. Профессионал отличается от ламмера не знанием того, чем версия 4564.4534.324.3242 Сам-API лучше версии 4564.4534.324.3241, а также знанием 1,000,000 разных API, а тем, что решает задачу наиболее эффективным способом, заа наименьшее время и с максимальным соблюдением ее постановки.
H_D>Пример1:
H_D>Если нужно сделать ОЧЕНЬ быстрый поиск в массиве целых чисел — он напишет реализацию на ассемблере
Ага-ага, на ассемблере, используя простой перебор... А рядом будет сидеть "ламмер", который на VB напишет тот же самый поиск, но предварительно отсортирует последовательность и использует бинарный поиск... Пора бы, мил чел, знать, что профессионал в прикладной задаче не станет ни за какие шиши опускаться до столь низкого уровня, зная, что, во-первых, современные компиляторы в исключительном бОльшинстве случаев выдадут значительно более эффективный код, а в-третьих, профессионал знает, что лучше сосредоточиться на решении задачи, чем тратить свое (очень дорогое, по рыночным меркам) время на подобное ребячество.
H_D>Пример2:
H_D>Если нужно просто окно для ввода пароля — он возьмет Дельфы или Васик (но никак не ВС — там хотя бы компиляция дольше идти будет).
Ты наивно полагаешь, что на MFC таковое окно сильно дольше делается? Ню-ню...
H_D>Таким образом кричать, что: "Дельфы — ламмерская система!!!!!!!!!!!", — потому, что аж завидки берут, как там просто и непринужденно можно писать достаточно мощные проекты,
Ой, батенька, а "мощные проекты" — это килобайт так на 100-200 кода? Угадал?

Тогда да. Такие "мощные проекты" там писать можно. Не слишком рационально в свете существования более совершенных .NET-систем, но таки можно.

H_D>ЗЫ Извините за резкозть — накипело. да и надоело слушать, что все надо выкинуть нафиг — все надо писать на Ц++ а базы данных реализовывать самостоятельно.

В действительности о Delphi, как таковой, можно забыть как о страшном сне. Borland ее развивать не будет. В более-менее серьезных проектах использовать Delphi, в виду убогости Object Pascal и, собственно, VCL, не рационально. Да и зачем, если есть .NET?..

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

H_D>Дельфи — это "RAD System — Rapid application Development System" т.е. система быстрой разработки приложений. нигде не вижу слов про БД... странно... то, что они исхитрились встроить в систему быстрый удобный и универсальный движок работы с БД — честь им и хвала.
Э-э, милсдарь, Вам бы не помешало заняться ликбезом и взглянуть хотя бы на ADO.NET BDE же, мягко говоря, окажется не у дел...

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

DS>>На Паскале на описалово одних локальных переменных в отдельной секции нрвов потратишь большк, чем в С++ на множественное наследование. Про все остальное вообще молчу: все эти многословные then, begin, end, procedure, functon и т.п.

VD>Ну тут тебе могут возразить что многим фигурные скобки кажутся очень неудобными, а бегин с этдом очень даже. Это просто дело вкуса. На качестве языка это не сильно сказывается.

VD>Если уж на то пошло, то нелюбимый тобой VB имеет почти идельную схему выделения блока кода. В нем просто нет ни скобок, ни мегинов:
Но есть then и сложная конструкция "End If" — скобки, однако, куда быстрее поставить.
VD>

VD>If bSome <> 0 Then
VD>  SomeWork
VD>End If
VD>

VD>Заметь, на С++ пришлось бы или добавлять лишнюю строку или оставлять первую скобку на строке с ифом. Второе просто хуже читается и делает неудобным пользование функции перехода по скобке в (Секд + [). Прим закрывающий
Чушь. Второе прекрасно читается. У нас это корпоративный стандарт:

if () {
...
} else {
...
}

VD>Паскль обделен такими сдедствами упрощения работы как шаблоны, макросы и множественное наследование. Но без них можно жить и даже создавать очень эффективные программы. В томже пращуне С++ языке С небыло ни шаблонов, ни множественного наследования, ни даже хоть какого нибудь наследования и тем не менее и сегодня на нем можно писать код скоростные характеристики которого близки к максимуму. В конечном итоге намного больше зависит от рук/головы программиста и от качества проектирования.
Не имеем шаблонов — вынуждены использовать приведение типов, что есть вред, т.к. понижение производительности приложения и программиста, а также понижение (потенциально) стабильности приложения.

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

A>Ей только в BCB "приятно" пользоваться, в Delphi она и на самом деле неплоха
В сравнении с VS+VA, IDEA, Eclipse и т.п. она на самом деле плоха.

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

H_D>>Так и с Дельфи — то, что вы не знаете профессионалов, которые великолепно владеют Delphi и умеют совмещать код Delphi с кодом на других ЯП (иногда — и в одном проекте) не значит, что таковых нет, а Дельфи — отстой... просто Борланд чуть лучше заботится о своих юзверях

V> Ага, особенно когда прекратила поддержку OWL и сказала "юзайте VCL или идите нах.".
А теперь ведь то же самое с VCL. "Юзайте .NET или идите нах". Впрочем, давно пора...

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

TL>>Да, Паскаль почти ничего не умеет.

Бейсик и тот лучше.

K>А что не умеет Паскаль и умеет С++?
K>(Про множественное наследование не надо

)
Шаблоны не умеет, перегрузку операторов не умеет, функции с переменным количеством параметров не умеет.
В итоге ни тебе патернов более-менее сложных (хотя бы интеллектуальных указателей, без которых сейчас никуда), ни тебе универсальных структур, специализируемых через шаблон на этапе компиляции. Да чего только стоит возможность инстанцирования (!) абстрактного класса!

Потому на Делфи дальше пользовательского интерфейса не уедешь.

Здравствуйте, Аноним, Вы писали:

TL>>>Да, Паскаль почти ничего не умеет.

Бейсик и тот лучше.

K>>А что не умеет Паскаль и умеет С++?
K>>(Про множественное наследование не надо

)

А>В принципе все умеет.
Шаблоны уже умеет? Перегрузку операторов? Функции с переменным числом параметров?... Словом, рекомендую не лезть в спор, не зная его предмета.

P.S. Ликбез: C != C++

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

DG>>Смотрел я на код Dos Navigator-а и я бы не сказал, что он хорошо написан (в плане структурированности).
КАА>И что? Не въехать в него с пол-тычка, это точно

. Мне код тоже не нравится. И что? От этого прога плохая стала? DN в своем роде уникум. Все плагины под фар щас повторяют DN фичи.
Чушь. Фаровских плагинов уже много-много больше всех вместе взятых фич DN.

iT>Мне например, немножко не нравится взятая из java схема, когда тело метода нельзя оторвать от его декларации... В паскале есть interface/implementation и это красиво. В C/C++ есть хедеры — тоже разнесены интерфейс и реализация...
В современных средах разработки при наличии пространств имен разнесение объявления (интерфейс это другое, в общепринятой терминологии) и реализации не просто не нужно, но скорее вредно, т.к. усложняет структуру программы и представляется лишней сущностью — атавизмом C-шных времен.

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

ST>Здравствуйте, Igor Trofimov, Вы писали:

Y>>>Извиняйте за небольшой офтопик, что Вы, уважаемые гуру межете сказать плохого
Y>>>про C#, если уже сравнивать его с Delphi и C.

iT>>Гуру — не гуру, но скажу

iT>>Мне например, немножко не нравится взятая из java схема, когда тело метода нельзя оторвать от его декларации... В паскале есть interface/implementation и это красиво. В C/C++ есть хедеры — тоже разнесены интерфейс и реализация...

ST>ИМХО отказ от разделения декларации и реализации ухудшает возможности разбиения на модули гораздо больше чем в Delphi по сравнению с C++. На что у изобретателей Java есть стандартный ответ : "если правильно проектировать ...".
Да при чем здесь это? Модульность изжила себя. Идеология пространств имен куда совершеннее хотя бы в виду иерархичности структуры и разрешения конфликтов имен.

Здравствуйте, Аноним, Вы писали:

А>Конечно, исключение.
А>Притом заметь, что это таки C++. IMHO, у Buildera гораздо лучше перспектвка,
Нет у него уже никаких перспектив. Борланд полностью отказалась от VCL в пользу .NET Стоит признать, правильно сделала.
А>чем у Delphi. Чего спорить, "бацанье" интерфейса у Борланда лучше чем у VC (все версии).
Смотрим на WinForms и забываем про VCL, как про страшный сон.

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

DG>>>Как видно из цитаты — пока есть только компилятор, а все остальное еще надо перенести на .Net.
A>>Хм. Всех обманули называется. Надо посмотреть будет.

iT>Кто тебя обманул? Они и не обещали полной поддержки .net в этом релизе. Вышедший продукт называется "Delphi 7", а не Delphi.Net
Delphi 7 ничего общего с .NET не имеет. А Delphi 8 не так давно появилась.

Для правдивости нужно сказать, что перегрузка функций в Delphi поддерживается. Как минимум начиная с версии 6.

Posted via RSDN NNTP Server 1.8 beta

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Для правдивости нужно сказать, что перегрузка функций в Delphi поддерживается. Как минимум начиная с версии 6.
Ты, наверное, имеешь в виду перегрузку операторов? Потому, что перегрузка функций (вместе с ключевым словом overload) появилась, дай байт памяти, то ли в 4 то ли в 5.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, <Аноним>, Вы писали:

А>Но есть then и сложная конструкция "End If" — скобки, однако, куда быстрее поставить.

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

А>Чушь.

Чушь — это ваши корп. стандарты. А читать лушче как раз как я приводил.

А> Второе прекрасно читается. У нас это корпоративный стандарт:

А>if () {
А> ...
А>} else {
А> ...
А>}

Хреново это читается.

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

Без приведения типов и на С++ нельзя. Хотя конечно чем их меньше, тем лучше. Ну, да хорошо спроектированная программа на любом языка старается их не делать. Что же касается стабильности, то тут С++ на последнем месте, так как язык не карантируем типобезопастности в рантайме. Молейшая ошибка и память испорчена...

... << RSDN@Home 1.1.3 beta 2 >>

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

DG>.Net пока в Delphi только для галочки.
DG>Цитирую: "в поставку включены предварительная версия компилятора Delphi for .Net и RTL.Net (библиотека времени выполнения, ориентированная на работу с платформой .Net), позволяющая естественным образом работать с любыми классами .Net Framework, включая работу с ASP.Net. Затем возможно появится VCL.Net, после чего будет выпущен окончательный релиз, за которым и последует Delphi.Net (проект Gallileo)

DG>Как видно из цитаты — пока есть только компилятор, а все остальное еще надо перенести на .Net.
Это ты путаешь с Delphi 7 и Delphi for .Net

Посмотри
http://www.rsdn.ru/Forum/Message.aspx?mid=548308&only=1
http://www.rsdn.ru/Forum/Message.aspx?mid=558365&only=1
http://www.rsdn.ru/Forum/Message.aspx?mid=559531&only=1

... << RSDN@Home 1.1.0 stable >>

DG>>.Net пока в Delphi только для галочки.
DG>>Цитирую: "в поставку включены предварительная версия компилятора Delphi for .Net и RTL.Net (библиотека времени выполнения, ориентированная на работу с платформой .Net), позволяющая естественным образом работать с любыми классами .Net Framework, включая работу с ASP.Net. Затем возможно появится VCL.Net, после чего будет выпущен окончательный релиз, за которым и последует Delphi.Net (проект Gallileo)

DG>>Как видно из цитаты — пока есть только компилятор, а все остальное еще надо перенести на .Net.
S> Это ты путаешь с Delphi 7 и Delphi for .Net

S> Посмотри
S> http://www.rsdn.ru/Forum/Message.aspx?mid=548308&only=1
S> http://www.rsdn.ru/Forum/Message.aspx?mid=558365&only=1
S> http://www.rsdn.ru/Forum/Message.aspx?mid=559531&only=1

Посмотри на дату моего сообщения.

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

DG>Посмотри на дату моего сообщения.
Да уж прошу прощение. Янус подгрузил только оборванные ветки.

... << RSDN@Home 1.1.0 stable >>

Почитал и решил высказать свое мнение. В настоящее время я разрабатываю систему интернет-трейдинга в финансовой компании, проекту уже 4 года. Интерфейсная часть написана на Delphi, есть также некоторое кол-во библиотек и подпроектов на C++.

Я считаю, что если есть необходимость создать Windows-приложение, в котором будет много формочек и нет ограничений (серьезных) на размер программы и на навыки программистов, то Delphi — отличный выбор, потому что:
1) VCL — достаточно продуманная и гибкая обертка для Windows GUI, которая берет на себя огромную часть рутины и позволяет программировать на высоком уровне абстракций (Button1.Caption := 'Ляля' и т.д.)
2) если возможностей VCL не хватает — можно переопределить оконную процедуру и обрабатывать самостоятельно специфические Windows-сообщения или использовать методы со свойством message.
3) Delphi — _модульная_ система программирования. Поэтому компиляция после исправления пары-тройки форм на моем компьютере занимает _ПАРУ СЕКУНД_.
Я очень ценю подобную скорость отклика, так как таков мой стиль программирования — быстро вносить изменения и смотреть что происходит.
С++ — не модульный язык. Даже включив всякие оптимизации компилирования, я очень долго __жду__

Это плохо.
А Дельфи замечательно переваривает большие проекты (скажем, сейчас у меня в проекте 118 юнитов из них 58 форм) — _никаких_ _тормозов_. Это замечательно.
4) Удобная среда, есть все что нужно и работает быстро.
5) Производимый компилятором код на мой взгляд очень неплох. Я имею в виду быстродействие там где оно нужно.

Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi

).

Далее, серьезный недостаток Delphi Pascal — отсутствие стековых объектов, все объекты — в дин. памяти и соот-но создание объекта и
его уничтожение приходится делать собственноручно. Т.е. C++:

{
SOME_STACK stack(some_parameter);
stack.push(123);
...
}
// stack уже автоматически уничтожен и его деструктор вызван

Delphi:

stack := TSomeStack.Create(some_parameter);
try
stack.push(123);
...
finally
stack.Free;
end;

Здесь C++ абсолютный лидер по лаконичности записи.

Шаблоны бы не помешали, но вообще говоря это не must have.

Вообщем, надеюсь главная мысль ясна. Дельфи — замечательная "обертка" для проекта под Windows, он легко "тянет" и маленькие, и большие проекты. А еще лучше он становится, если его доработать своими собственными библиотеками (хоть на C++, хоть на чем еще

. И под него удобно делать и ActiveX-ы и еще много чего другого.

PS Один из отцов-основателей Delphi ушел в Microsoft разрабатывать C#, так что нетрудно заметить как отличные идеи в Delphi (скажем as и is) переползли в C#.

PPS К сожалению, Delphi конец.

Мы получим еше одно обновление Delphi 7.1, после чего будет развиваться только Delphi .NET.
Король умер, да здравствует король.

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

G_>Далее, серьезный недостаток Delphi Pascal — отсутствие стековых объектов, все объекты — в дин. памяти и соот-но создание объекта и
G_>его уничтожение приходится делать собственноручно.

http://www.rsdn.ru/Forum/?mid=394033
http://www.rsdn.ru/Forum/Message.aspx?mid=551579&only=1
http://www.rsdn.ru/Forum/Message.aspx?mid=551720&only=1

... << RSDN@Home 1.1.0 stable >>

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

А>>Но есть then и сложная конструкция "End If" — скобки, однако, куда быстрее поставить.
VD>Быстрее всего не поставить, а положить или забить. Языки же сделаны чтобы их читать. Проблемы писателей всех интересуют в последнюю очередь.
Языки созданы для того, чтобы на них писать — в первую очередь. Именно потому популярность у профессионалов приобрели клоны C-синтаксиса, а не Pascal, Basic или тому подобного.

А>>Чушь.
VD>Чушь — это ваши корп. стандарты. А читать лушче как раз как я приводил.
Сарказм не виден? Я к тому, что такие категоричные заявления непрофессиональны.

А>> Второе прекрасно читается. У нас это корпоративный стандарт:

А>>if () {
А>> ...
А>>} else {
А>> ...
А>>}

VD>Хреново это читается.
Ну конечно-конечно... Уж кто бы сомневался.

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

VD>Без приведения типов и на С++ нельзя.
В действительности можно, если сильно захотеть. Вопрос в профессиональном опыте, коего Вам, судя по всему, не хватает. Не обессудьте.
VD>Хотя конечно чем их меньше, тем лучше. Ну, да хорошо спроектированная программа на любом языка старается их не делать. Что же касается стабильности, то тут С++ на последнем месте, так как язык не карантируем типобезопастности в рантайме. Молейшая ошибка и память испорчена...
Да-да, вопрос профессионального уровня.

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Для правдивости нужно сказать, что перегрузка функций в Delphi поддерживается. Как минимум начиная с версии 6.
А разве я говорил, что не перегрузка функций не поддерживается (с D4, кстати)? Нет. Будьте внимательнее.

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

S>Здравствуйте, Евгений Коробко, Вы писали:

ЕК>>Для правдивости нужно сказать, что перегрузка функций в Delphi поддерживается. Как минимум начиная с версии 6.
S>Ты, наверное, имеешь в виду перегрузку операторов? Потому, что перегрузка функций (вместе с ключевым словом overload) появилась, дай байт памяти, то ли в 4 то ли в 5.
А перегрузки операторов и в 7-ой нету.

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

G_>Почитал и решил высказать свое мнение. В настоящее время я разрабатываю систему интернет-трейдинга в финансовой компании, проекту уже 4 года. Интерфейсная часть написана на Delphi, есть также некоторое кол-во библиотек и подпроектов на C++.

G_>Я считаю, что если есть необходимость создать Windows-приложение, в котором будет много формочек и нет ограничений (серьезных) на размер программы и на навыки программистов, то Delphi — отличный выбор, потому что:
Точнее — была отличным выбором (и то с большим количеством "но"). Теперь отличный выбор — .NET WinForms (не без "но" конечно тоже). VCL дальше развиваться не будет, поэтому использовать ее в новых проектах... крайне неразумно.

G_>1) VCL — достаточно продуманная и гибкая обертка для Windows GUI, которая берет на себя огромную часть рутины и позволяет программировать на высоком уровне абстракций (Button1.Caption := 'Ляля' и т.д.)
То же самое в WinForms. Как, впрочем, и в VBx(x<7) в связке с ActiveX-компонентами.

G_>2) если возможностей VCL не хватает — можно переопределить оконную процедуру и обрабатывать самостоятельно специфические Windows-сообщения или использовать методы со свойством message.
Но нету PreProcessMessage

G_>3) Delphi — _модульная_ система программирования. Поэтому компиляция после исправления пары-тройки форм на моем
Вовсе не поэтому, а потому что компилятор однопроходный. Кстати, попробуй инстанцировать чистый абстрактный класс — результат тебя удивит... вероятно.

G_>компьютере занимает _ПАРУ СЕКУНД_.
Э-э... Это на проекте, которому уже 4 года? Позволю себе не поверить.

G_>Я очень ценю подобную скорость отклика, так как таков мой стиль программирования — быстро вносить изменения и смотреть что происходит.
Это вредная привычка. Проведи терапию парой сеанцев с достаточно большим количеством ATL/WTL/STL/своего шаблонного кода C++

В действительности, мелкие ошибки должны выявляться средой разработки по ходу написания кода без компиляции (см., например, VS.NET, IDEA и т.п.)

G_>С++ — не модульный язык. Даже включив всякие оптимизации компилирования, я очень долго __жду__

Это плохо.
Плохо то, что ты не знаешь, что такое "модульный язык".

Тут дело в другом — компиляторы C++ двупроходные.

G_>А Дельфи замечательно переваривает большие проекты (скажем, сейчас у меня в проекте 118 юнитов из них 58 форм) — _никаких_ _тормозов_. Это замечательно.
По секрету скажу, что 58 форм и 118 юнитов — это *не*большой проект. Ну разве что средний размер одного юнита у тебя — 1MB

G_>4) Удобная среда, есть все что нужно и работает быстро.
Удобная среда заканчивается там, где заканчивается мышевозня, то бишь при выходе из дизайнера форм (который, кстати, тоже далеко не идеален — есть и более интересные решения).

G_>5) Производимый компилятором код на мой взгляд очень неплох. Я имею в виду быстродействие там где оно нужно.
Перефразируем: для бОльшинства задач код, выдаваемый компилятором Delphi, вполне нормален. Там, где, например, начинается большое количество математики компилятор Delphi сильно уступает, например, компилятору Intel C++. Кстати, инлайнить код и генерировать типизированный на основе шаблонов, компилятор Delphi не умеет.

G_>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi

).
В бОльшинстве случаев интереснее hash_map. А еще нету интеллектуальных указателей, без коих много-много сложнее...

G_>Далее, серьезный недостаток Delphi Pascal — отсутствие стековых объектов, все объекты — в дин. памяти и соот-но создание объекта и его уничтожение приходится делать собственноручно. Т.е. C++:
Таких примеров можно привести еще очень много. Поэтому я и говорю, что все удобства в Delphi заканчиваются, когда заканчивается мышевозня...

G_>Шаблоны бы не помешали, но вообще говоря это не must have.
Это must have однозначно, потому как: валидация во время компиляции, потому как: универсальный строго типизированный код без надобности кастования типов (list<int>, list<string> ...), потому как: патерны (smartpointer, class factory, singleton и т.д. и т.д.).

G_>Вообщем, надеюсь главная мысль ясна. Дельфи — замечательная "обертка" для проекта под Windows, он легко "тянет" и маленькие, и большие проекты.
Маленькие, да, тянет. Большие... — разве что у мазохистов/энтузиастов.

G_>А еще лучше он становится, если его доработать своими собственными библиотеками (хоть на C++, хоть на чем еще

. И под него удобно делать и ActiveX-ы и еще много чего другого.
ActiveX, как и VCL — мертвые технологии, потому что MS официально отказалась от COM в пользу .NET (которая с лихвой покрывает функциональность COM), потому что Borland отказалась от VCL в пользу .NET Framework (которая с лихвой покрывает функциональность VCL).

G_>PS Один из отцов-основателей Delphi ушел в Microsoft разрабатывать C#, так что нетрудно заметить как отличные идеи в Delphi (скажем as и is) переползли в C#.
А с чего ты взял, что эти идеи принадлежат Borland?

Кстати, ничего отличного в них не вижу. Как и невижу ничего хорошего во всевсяческих кастованиях типов (что во многих случаях есть костыль при отсутствии шаблонов).

Здравствуйте, <Аноним>, Вы писали:
А>А перегрузки операторов и в 7-ой нету.
Смотря для каких типов

... << RSDN@Home 1.1.3 beta 2 >>

G_>>Далее, серьезный недостаток Delphi Pascal — отсутствие стековых объектов, все объекты — в дин. памяти и соот-но создание объекта и
G_>>его уничтожение приходится делать собственноручно.

S>http://www.rsdn.ru/Forum/?mid=394033
S>http://www.rsdn.ru/Forum/Message.aspx?mid=551579&only=1
S>http://www.rsdn.ru/Forum/Message.aspx?mid=551720&only=1

Спасибо что напомнили про object, но:

Since object types do not descend from TObject, they provide no built-in constructors, destructors, or other methods. You can create instances of an object type using the New procedure and destroy them with the Dispose procedure, or you can simply declare variables of an object type, just as you would with records.

Т.е. нет у них конструкторов и деструкторов. Отсюда их неполноценность. 1) — объект придется инициализировать руками,
поскольку несмотря на то, что он будет лежать на стеке, как мы понимаем, в его полях будет мусор.
2) если объект выделяет динамический ресурс, то надо не забыть "дернуть" деструктор.
Вообще получается на нас опять ложится вся эта рутина, а прелесть стековых объектов в C++ именно в том, что у них есть и конструктор и деструктор
и они корректно вызываются, в том числе и при бросании исключений. И всю работу компилятор делает за нас.
Это позволяет пользоваться техникой Resource Managment (то есть выделять ресурс в конструкторе и освобождать в деструкторе)
ну и делать другие приятные вещи.

Повторюсь — в Delphi это достигается через try ... finally, это хорошая штука но опять-таки больше печатать.

G_>>Почитал и решил высказать свое мнение. В настоящее время я разрабатываю систему интернет-трейдинга в финансовой компании, проекту уже 4 года. Интерфейсная часть написана на Delphi, есть также некоторое кол-во библиотек и подпроектов на C++.

G_>>Я считаю, что если есть необходимость создать Windows-приложение, в котором будет много формочек и нет ограничений (серьезных) на размер программы и на навыки программистов, то Delphi — отличный выбор, потому что:
А>Точнее — была отличным выбором (и то с большим количеством "но"). Теперь отличный выбор — .NET WinForms (не без "но" конечно тоже). VCL дальше развиваться не будет, поэтому использовать ее в новых проектах... крайне неразумно.

Я бы поспорил. Для нашего приложения, например, (да и для других тоже) критичным является то, что у пользователя может стоять любая Windows на его
домашнем компьютере. И он скачает установочный пакет размером 2 Mb и начнет работать (торговать акциями).

В случае .NET возникают 2 проблемы —
a) не уверен что Windows 95/98/ME/NT поддерживает .NET, надо посмотреть, но какие-то Windows из перечисленных точно не поддерживаются
b) надо скачать и установить ран-тайм для .NET.
Вот у меня лежит dotnetfx.exe, его размер — 24265736 байт.
Для кого-то это все ерунда (у него допустим Windows 2003 стоит, где уже есть .NET framework),
а кого-то из клиентов это оттолкнет. А для компании важны все клиенты, сами понимаете

G_>>1) VCL — достаточно продуманная и гибкая обертка для Windows GUI, которая берет на себя огромную часть рутины и позволяет программировать на высоком уровне абстракций (Button1.Caption := 'Ляля' и т.д.)
А>То же самое в WinForms. Как, впрочем, и в VBx(x<7) в связке с ActiveX-компонентами.

Ну нет. Я согласен, что WinForms как и C# и .NET — хорошая вещь (а как ей не быть таковой, если Microsoft опять .... как бы это выразиться ...
ну скажем позаимствовала все самые лучше идеи для разработки

Но VB с ActiveX — не предлагать!!!
Это мертворожденная технология (как VB так и ActiveX) и серьезные вещи на них делать не стоит.

G_>>2) если возможностей VCL не хватает — можно переопределить оконную процедуру и обрабатывать самостоятельно специфические Windows-сообщения или использовать методы со свойством message.
А>Но нету PreProcessMessage

Я же говорю:

procedure TfmChildWindow.FormCreate(Sender: TObject);
begin
SetWindowLong(Handle, GWL_USERDATA, Integer(self));
OldProc := Pointer(SetWindowLong(Handle, GWL_WNDPROC, integer(@ClientWindowProc)));
end;

function ClientWindowProc(wnd: HWND; msg: Cardinal; wparam, lparam: Integer ): Integer; stdcall;
var
fmChildWindow: TfmChildWindow;
Begin

fmChildWindow := TfmChildWindow(GetWindowLong(wnd, GWL_USERDATA));

case msg of

WM_SIZING, WM_MOVING:
// тра-ля-ля ...

;

end;

result := CallWindowProc(fmChildWindow.OldProc, wnd, msg, wparam, lparam);
end;

G_>>3) Delphi — _модульная_ система программирования. Поэтому компиляция после исправления пары-тройки форм на моем
А>Вовсе не поэтому, а потому что компилятор однопроходный. Кстати, попробуй инстанцировать чистый абстрактный класс — результат тебя удивит... вероятно.

А зачем это делать??

G_>>компьютере занимает _ПАРУ СЕКУНД_.
А>Э-э... Это на проекте, которому уже 4 года? Позволю себе не поверить.

Только что сделал полный build проекту. Первый раз — 15 секунд. Последующие build (_build_!) — 2-3 секунды (потому как все попало в кеш видимо).
Напоминаю — build: полное перепостроение всего кода. Размер результирующего приложения: 2253824 байта.
Общий размер всех pas файлов в проекте — 1.096.671 байт.
У меня Windows 2000, памяти 512, процессор — около 2 Ghz, точно не помню. Вопросы?

G_>>Я очень ценю подобную скорость отклика, так как таков мой стиль программирования — быстро вносить изменения и смотреть что происходит.
А>Это вредная привычка. Проведи терапию парой сеанцев с достаточно большим количеством ATL/WTL/STL/своего шаблонного кода C++

В действительности, мелкие ошибки должны выявляться средой разработки по ходу написания кода без компиляции (см., например, VS.NET, IDEA и т.п.)

Это уведет нас в сторону, но опять-таки таков мой стиль — я люблю проводить быстрые эксперименты — написать пробный код и тут же посмотреть
его в деле — и Delphi очень помогает в этом.

G_>>С++ — не модульный язык. Даже включив всякие оптимизации компилирования, я очень долго __жду__

Это плохо.
А>Плохо то, что ты не знаешь, что такое "модульный язык".

Тут дело в другом — компиляторы C++ двупроходные.

Под модульным в данном случае я подразумеваю схему компиляции и линковки.

G_>>А Дельфи замечательно переваривает большие проекты (скажем, сейчас у меня в проекте 118 юнитов из них 58 форм) — _никаких_ _тормозов_. Это замечательно.
А>По секрету скажу, что 58 форм и 118 юнитов — это *не*большой проект. Ну разве что средний размер одного юнита у тебя — 1MB

Ну все относительно конечно

Мой предыдущий большой дельфийский проект насчитывал более 100 форм. А каков Ваш наибольший проект?
Или это из серии "я видел людей которые видели людей которые видели Ленина"?

G_>>4) Удобная среда, есть все что нужно и работает быстро.
А>Удобная среда заканчивается там, где заканчивается мышевозня, то бишь при выходе из дизайнера форм (который, кстати, тоже далеко не идеален — есть и более интересные решения).

Аргументы?

G_>>5) Производимый компилятором код на мой взгляд очень неплох. Я имею в виду быстродействие там где оно нужно.
А>Перефразируем: для бОльшинства задач код, выдаваемый компилятором Delphi, вполне нормален. Там, где, например, начинается большое количество математики компилятор Delphi сильно уступает, например, компилятору Intel C++. Кстати, инлайнить код и генерировать типизированный на основе шаблонов, компилятор Delphi не умеет.

1) для специальных задач специальное решение всегда лучше типового решения. Если инженеры Intel не спят ночами и роясь в мануалах по семейству
x86 изыскивают методы ускорения расчетов — разумеется — их код всегда будет лучше кода компилятора Дельфи. Но умные люди (как мы с вами) никогда
ведь и не будут использовать бейсик для написания движка физики в игре, правильно?
Ес-но если взять и самому написать sin(x) * cos(sin(y)) на стеке сопроцессора, то это будет работать быстрее чем код, сгенеренный Дельфи (потому
как тот ес-но не будет исходить из предположения что все влезет на стек, а построит более общую схему расчта). Кто с этим спорит?

2) инлайн... ну да, наверное. тем не менее на Дельфи можно писать полностью ассемблерные процедуры с минимальным overhead, что может и отменит
необходимость в инлайн.

3) насчет шаблонов я уже говорил. да их нет, но это не критично.

G_>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi

).
А>В бОльшинстве случаев интереснее hash_map. А еще нету интеллектуальных указателей, без коих много-много сложнее...

Ну да. Вот это действительно беда Delphi. Даже в Яве есть набор замечательных структур с добавлением/поиском/удалением за O(log n)...

G_>>Далее, серьезный недостаток Delphi Pascal — отсутствие стековых объектов, все объекты — в дин. памяти и соот-но создание объекта и его уничтожение приходится делать собственноручно. Т.е. C++:
А>Таких примеров можно привести еще очень много. Поэтому я и говорю, что все удобства в Delphi заканчиваются, когда заканчивается мышевозня...

Я предпочитаю говорить о конкретных недостатках...

G_>>Шаблоны бы не помешали, но вообще говоря это не must have.
А>Это must have однозначно, потому как: валидация во время компиляции, потому как: универсальный строго типизированный код без надобности кастования типов (list<int>, list<string> ...), потому как: патерны (smartpointer, class factory, singleton и т.д. и т.д.).

Шаблоны это замечательно, согласен. Кстати, они появились в Яве (1.5). Но повторяюсь в третий раз — можно пережить и без них.

G_>>Вообщем, надеюсь главная мысль ясна. Дельфи — замечательная "обертка" для проекта под Windows, он легко "тянет" и маленькие, и большие проекты.
А>Маленькие, да, тянет. Большие... — разве что у мазохистов/энтузиастов.

Аргументы?

G_>>А еще лучше он становится, если его доработать своими собственными библиотеками (хоть на C++, хоть на чем еще

. И под него удобно делать и ActiveX-ы и еще много чего другого.
А>ActiveX, как и VCL — мертвые технологии, потому что MS официально отказалась от COM в пользу .NET (которая с лихвой покрывает функциональность COM), потому что Borland отказалась от VCL в пользу .NET Framework (которая с лихвой покрывает функциональность VCL).

Напоминаю — проекту 4 года

А 3 года назад ActiveX + ASP было весьма распространенное явление.

G_>>PS Один из отцов-основателей Delphi ушел в Microsoft разрабатывать C#, так что нетрудно заметить как отличные идеи в Delphi (скажем as и is) переползли в C#.
А>А с чего ты взял, что эти идеи принадлежат Borland?

Кстати, ничего отличного в них не вижу. Как и невижу ничего хорошего во всевсяческих кастованиях типов (что во многих случаях есть костыль при отсутствии шаблонов).

Да я не о том, что кому принадлежит. Я к тому, что .NET вобрала в себя лучшее и безусловно будет доминировать.

as и is — не обязательно "костыль"

Простейший пример — обход контролов на форме с целью прописывания только лейблам какого-то свойства.
Простой, наглядный код с as и is. (а не static_cast<label> и пр.)

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

G_>1) VCL — достаточно продуманная и гибкая обертка для Windows GUI, которая берет на себя огромную часть рутины и позволяет программировать на высоком уровне абстракций (Button1.Caption := 'Ляля' и т.д.)
G_>2) если возможностей VCL не хватает — можно переопределить оконную процедуру и обрабатывать самостоятельно специфические Windows-сообщения или использовать методы со свойством message.
То-то же до сих пор Юникода в ней нет. В NT юникодные контролки были изначально, в 9x появились в IE5 (т.е. начиная с Win98SE есть в штатной поставке)

G_>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки.
Это Вы о VCL? Тогда согласен

By the grace of God Almighty
And the pressures of a marketplace
The human race has civilized itself
It's a miracle

G_>>1) VCL — достаточно продуманная и гибкая обертка для Windows GUI, которая берет на себя огромную часть рутины и позволяет программировать на высоком уровне абстракций (Button1.Caption := 'Ляля' и т.д.)
G_>>2) если возможностей VCL не хватает — можно переопределить оконную процедуру и обрабатывать самостоятельно специфические Windows-сообщения или использовать методы со свойством message.
SC>То-то же до сих пор Юникода в ней нет. В NT юникодные контролки были изначально, в 9x появились в IE5 (т.е. начиная с Win98SE есть в штатной поставке)

Увы, Unicode нет. Но. Во-первых, есть:

http://tnt.ccci.org/delphi_unicode_controls/

То бишь сторонние решения, полностью совместимые по коду.

Во-вторых, потребность в Unicode есть все же не в каждом проекте.

В-третьих, даже если в 9x и появились эти самые Unicode-контролы это не значит, что 9x стали поддерживать Unicode.

G_>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки.
SC>Это Вы о VCL? Тогда согласен

Я же вроде бы написал подробно, что имел в виду. Вы до конца сообщения дочитали?
Или этот взрыв эмоций не совместим с рациональным мышлением?

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

G_>и они корректно вызываются, в том числе и при бросании исключений. И всю работу компилятор делает за нас.
G_>Это позволяет пользоваться техникой Resource Managment (то есть выделять ресурс в конструкторе и освобождать в деструкторе)
G_>ну и делать другие приятные вещи.

G_>Повторюсь — в Delphi это достигается через try ... finally, это хорошая штука но опять-таки больше печатать.
Но в С++ за тебя это делает компилятор оборачивая все через дополнительный код. Хорошо это или плохо ситуации разные бывают иногда нужен полный котроль над кодом.
Работая же в Net и потом переходя в нативный Delphi вызов деструкторов уже начинаешь игнорировать.
Delphi отличный язык с метаклассами продуманной иерархией и базового класса и прежде всего силен в сложный иерархических моделях, что мы видим в Net и Java.
И для того времени когда был создан считаю его революционным, но к сожалению кроме компоненто строительства принципиальных изменений внесено не было. Курс на Net считаю правильным, но придется сильно напрячся. К тому же Хэйлсберг в лагере M$ а C# стандарт дефакто, хотя и не без изъянов.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, <Аноним>, Вы писали:

G_>>PS Один из отцов-основателей Delphi ушел в Microsoft разрабатывать C#, так что нетрудно заметить как отличные идеи в Delphi (скажем as и is) переползли в C#.
А>А с чего ты взял, что эти идеи принадлежат Borland?

Кстати, ничего отличного в них не вижу. Как и невижу ничего хорошего во всевсяческих кастованиях типов (что во многих случаях есть костыль при отсутствии шаблонов).
Не боись дженерики заменят шаблоны. А насчет Хэйлсбега ты зря. Можно спорить на что Net (Delph.Net,C#) похож на Java или Delphi но общего у них очень много.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, <Аноним>, Вы писали:

G_>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi

).
А>В бОльшинстве случаев интереснее hash_map. А еще нету интеллектуальных указателей, без коих много-много сложнее...

Который пишется часа за два с нуля, а типизируется за 2 минуты.
http://www.rsdn.ru/Forum/Message.aspx?mid=419818&only=1
http://www.rsdn.ru/Forum/Message.aspx?mid=437992&only=1

И все остальные векторы мапы итд. Это не проблема.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, <Аноним>, Вы писали:

А>А перегрузки операторов и в 7-ой нету.
В 8 ой есть. Не видел еще 7.1 но говорят должна многое поддерживать для перехода на Net.
Кстати перегрузка операторов хороша для шаблонов и кодогенерации. в Net этим редко пользуются.

... << RSDN@Home 1.1.0 stable >>

G_>>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi

).
А>>В бОльшинстве случаев интереснее hash_map. А еще нету интеллектуальных указателей, без коих много-много сложнее...

S> Который пишется часа за два с нуля, а типизируется за 2 минуты.
S> http://www.rsdn.ru/Forum/Message.aspx?mid=419818&only=1
S>http://www.rsdn.ru/Forum/Message.aspx?mid=437992&only=1

S> И все остальные векторы мапы итд. Это не проблема.

Не согласен.

1. создать нормальный мап — совершенно нетривиальная задача! (ну-ка давайте-ка по памяти напишем процедурку удаления узла из красно-черного или AVL дерева, слабо?)

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

То, что STL появилась на свет и успешно существует и очень многими используется доказывает мою правоту.

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

G_>>>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi

).
А>>>В бОльшинстве случаев интереснее hash_map. А еще нету интеллектуальных указателей, без коих много-много сложнее...

S>> Который пишется часа за два с нуля, а типизируется за 2 минуты.
S>> http://www.rsdn.ru/Forum/Message.aspx?mid=419818&only=1
S>>http://www.rsdn.ru/Forum/Message.aspx?mid=437992&only=1

S>> И все остальные векторы мапы итд. Это не проблема.

G_>Не согласен.

G_>1. создать нормальный мап — совершенно нетривиальная задача! (ну-ка давайте-ка по памяти напишем процедурку удаления узла из красно-черного или AVL дерева, слабо?)
Блин я этих деревьев перенаписал блевать на них хочется.

G_>2. стандартизация — великая вещь, а так у каждого будут в проекте свои контейнеры и свои способы работы с ними и т.д., это очень плохо

Предпочитаю свои классы, т.к. стандартные как правило ограничены.
G_>То, что STL появилась на свет и успешно существует и очень многими используется доказывает мою правоту.
Пользоваться можно чем угодно в том числе и генераторами кода.
А против стандарта и корпоративного кодирования ничего против не имею, только скучно.

... << RSDN@Home 1.1.0 stable >>

G_>>>>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi

).
А>>>>В бОльшинстве случаев интереснее hash_map. А еще нету интеллектуальных указателей, без коих много-много сложнее...

S>>> Который пишется часа за два с нуля, а типизируется за 2 минуты.
S>>> http://www.rsdn.ru/Forum/Message.aspx?mid=419818&only=1
S>>>http://www.rsdn.ru/Forum/Message.aspx?mid=437992&only=1

S>>> И все остальные векторы мапы итд. Это не проблема.

G_>>Не согласен.

G_>>1. создать нормальный мап — совершенно нетривиальная задача! (ну-ка давайте-ка по памяти напишем процедурку удаления узла из красно-черного или AVL дерева, слабо?)
S>Блин я этих деревьев перенаписал блевать на них хочется.

G_>>2. стандартизация — великая вещь, а так у каждого будут в проекте свои контейнеры и свои способы работы с ними и т.д., это очень плохо

S> Предпочитаю свои классы, т.к. стандартные как правило ограничены.

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

Я тоже написал в свое время Б-дерево, идея возникла за 15 минут, реализация — за день. Только вот
_нормальное_работающее_Б-дерево_, охваченное итераторами, оптимизированное где нужно, с самопроверкой и пр. взошло не один месяц спустя.

Мое самое оптимизированное Б-дерево все равно было медленнее map примерно в 1.5 раза.

G_>>То, что STL появилась на свет и успешно существует и очень многими используется доказывает мою правоту.
S> Пользоваться можно чем угодно в том числе и генераторами кода.
S> А против стандарта и корпоративного кодирования ничего против не имею, только скучно.

Да уж, зато вставить в свою программу глючный компонент, обрушить пару сотен терминалов в самый разгар торгов,
получить сотню одновременных звонков на предмет невозможности торговать от клиентов, кучу претензий, удары по всем
частям тела от хедпдеска и от начальства и от начальства начальства — быстро начинать править код, каждый
5 сек. дергаемый словами "ну что готово" и "там опять все упало", быстро раздать это все какой-то паре сотен клиентов — вот ерунда-то! — это конечно не скучно, это очень весело!!!!!

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

S>> Предпочитаю свои классы, т.к. стандартные как правило ограничены.

G_>Это спор разработчика-одиночки и разработчика-члена-команды. Понятно, что свои компоненты ближе к сердцу и можно делать с ними все что
G_>угодно, только иногда как ни странно важна стандартизация и абсолютная безглючность, проверенная временем.

G_>Я тоже написал в свое время Б-дерево, идея возникла за 15 минут, реализация — за день. Только вот
G_>_нормальное_работающее_Б-дерево_, охваченное итераторами, оптимизированное где нужно, с самопроверкой и пр. взошло не один месяц спустя.

Когда опираешься на собственные реализации алгоритмов и проверенные временем то они становятся для меня уже стандартными.
Кстати многие сишникиеи простейших алгоритмов не знают. Зато знают вектор map итд. А переходя на C# руки опускаются.
G_>Мое самое оптимизированное Б-дерево все равно было медленнее map примерно в 1.5 раза.
Значит таков алгоритм или его реализация. А под мап можно подогнать и Хэш таблицы и BitArray и B+ деревья и просто массив и у всех есть плюсы и минусы и своя область применения.

G_>>>То, что STL появилась на свет и успешно существует и очень многими используется доказывает мою правоту.
S>> Пользоваться можно чем угодно в том числе и генераторами кода.
S>> А против стандарта и корпоративного кодирования ничего против не имею, только скучно.

G_>Да уж, зато вставить в свою программу глючный компонент, обрушить пару сотен терминалов в самый разгар торгов,
G_>получить сотню одновременных звонков на предмет невозможности торговать от клиентов, кучу претензий, удары по всем
G_>частям тела от хедпдеска и от начальства и от начальства начальства — быстро начинать править код, каждый
G_>5 сек. дергаемый словами "ну что готово" и "там опять все упало", быстро раздать это все какой-то паре сотен клиентов — вот ерунда-то! — это конечно не скучно, это очень весело!!!!!
Значит не надо делать глючные компоненты. А своих багов добавить и простейший код всегда пожалуйста, а во многом юзерский код оказывается намного алгоритмически сложнее чем стандартные библиотеки где кода 10 строчек.
Не ошибается тот кто ничего не делает, а кривизны в стандартных библиотеках хватает выше крыши как в Delphi, Net, Java.
Нет кривизны только в STL !!!!!!

... << RSDN@Home 1.1.0 stable >>

А>В действительности о Delphi, как таковой, можно забыть как о страшном сне. Borland ее развивать не будет. В более-менее серьезных проектах использовать Delphi, в виду убогости Object Pascal и, собственно, VCL, не рационально. Да и зачем, если есть .NET?.

Могу допустить убогость VCL, но вопрос в чес убогость Object Pascal?

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

S> Не ошибается тот кто ничего не делает, а кривизны в стандартных библиотеках хватает выше крыши как в Delphi, Net, Java.
Можно узнать перечень "кривизны" в .NET? И что подразумевается под "выше крыши", применительно к кривизне .NET?
S> Нет кривизны только в STL !!!!!!
Ага... Особенно в std::auto_ptr.
Задумайтесь, почему многие предпочитают заменять "стандартный" STL в VС++ на STLPort, а вместо std::auto_ptr использовать boost::shared_ptr

... << RSDN@Home 1.1.3 stable >>

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

G_>Вот у меня лежит dotnetfx.exe, его размер — 24265736 байт.
G_>Для кого-то это все ерунда (у него допустим Windows 2003 стоит, где уже есть .NET framework),
G_>а кого-то из клиентов это оттолкнет. А для компании важны все клиенты, сами понимаете

В действительности, если уж клиент может позволить себе преобрести ваше ПО, то и скачать 25-30MB для него труда не составит, потому как это копейки.

G_>>>1) VCL — достаточно продуманная и гибкая обертка для Windows GUI, которая берет на себя огромную часть рутины и позволяет программировать на высоком уровне абстракций (Button1.Caption := 'Ляля' и т.д.)
А>>То же самое в WinForms. Как, впрочем, и в VBx(x<7) в связке с ActiveX-компонентами.
G_>Ну нет. Я согласен, что WinForms как и C# и .NET — хорошая вещь (а как ей не быть таковой, если Microsoft опять .... как бы это выразиться ...
G_>ну скажем позаимствовала все самые лучше идеи для разработки

А что Вы в этом видите предосудительного? Разве чьи-то авторские права были нарушены?
G_>Но VB с ActiveX — не предлагать!!!
G_>Это мертворожденная технология (как VB так и ActiveX) и серьезные вещи на них делать не стоит.
Тем не менее, на них куда больше действительно серьезных коммерческих проектов. Пример Microstrategy. Разве есть что-то близкое по классу, но написанное на VCL? Я лично не знаю. Так что Вы весьма заблуждаетеся. Delphi (CBuilder) на западе распространены значительно в меньшей степени, чем VB, C++ или Java. Только на просторах постсоветских стран Delphi и CBuilder на столько популярны, что даже в институтах по ним читают целые курсы лекций...

G_>>>2) если возможностей VCL не хватает — можно переопределить оконную процедуру и обрабатывать самостоятельно специфические Windows-сообщения или использовать методы со свойством message.
А>>Но нету PreProcessMessage

G_>Я же говорю:
PreProcessMessage позволяет обработать сообщение непосредственно перед dispatch.

G_>>>3) Delphi — _модульная_ система программирования. Поэтому компиляция после исправления пары-тройки форм на моем
А>>Вовсе не поэтому, а потому что компилятор однопроходный. Кстати, попробуй инстанцировать чистый абстрактный класс — результат тебя удивит... вероятно.

G_>А зачем это делать??

Делать этого конечно не нужно, но компилятор Делфи, к сожалению, позволяет это сделать.

G_>>>компьютере занимает _ПАРУ СЕКУНД_.
А>>Э-э... Это на проекте, которому уже 4 года? Позволю себе не поверить.
G_>Только что сделал полный build проекту. Первый раз — 15 секунд. Последующие build (_build_!) — 2-3 секунды (потому как все попало в кеш видимо).
G_>Напоминаю — build: полное перепостроение всего кода. Размер результирующего приложения: 2253824 байта.
G_>Общий размер всех pas файлов в проекте — 1.096.671 байт.
1MB для всех файлов? Так это ма-а-ахонький проектик.

Как Вам удалось растянуть его на 4 года?

G_>>>С++ — не модульный язык. Даже включив всякие оптимизации компилирования, я очень долго __жду__

Это плохо.
А>>Плохо то, что ты не знаешь, что такое "модульный язык".

Тут дело в другом — компиляторы C++ двупроходные.
G_>Под модульным в данном случае я подразумеваю схему компиляции и линковки.
Модульная схема компиляции и линковки? А как это?

G_>>>А Дельфи замечательно переваривает большие проекты (скажем, сейчас у меня в проекте 118 юнитов из них 58 форм) — _никаких_ _тормозов_. Это замечательно.
А>>По секрету скажу, что 58 форм и 118 юнитов — это *не*большой проект. Ну разве что средний размер одного юнита у тебя — 1MB

G_>Ну все относительно конечно

Мой предыдущий большой дельфийский проект насчитывал более 100 форм. А каков Ваш наибольший проект?
G_>Или это из серии "я видел людей которые видели людей которые видели Ленина"?

Большие проекты насчитывают сотни мегабайт исходного кода (только кода, заметьте).

G_>>>4) Удобная среда, есть все что нужно и работает быстро.
А>>Удобная среда заканчивается там, где заканчивается мышевозня, то бишь при выходе из дизайнера форм (который, кстати, тоже далеко не идеален — есть и более интересные решения).
G_>Аргументы?
Навскидку:
1. Гайдлайны в дизайнере форм MFC/ATL/WTL.
2. Layout manager`ы в дизайнерах форм Java, .NET
3. Размещение невизуальных компонентов вне пределов формы на отдельной специально предназначенной области в дизайнере форм VS.NET
4. Локинг элементов на форме там же.
5. Удобный визуальный tab ordering в дизайнере форм MFC/ATL/WTL.
...

G_>2) инлайн... ну да, наверное. тем не менее на Дельфи можно писать полностью ассемблерные процедуры с минимальным overhead, что может и отменит необходимость в инлайн.
Ассемблерные вставки ухудшают читабельность кода и являются потенциальным глюкодромом, не избавляя тем не менее от overhead`а. В C++ компилятор сам может догадаться проинлайнить тот, либо иной метод.

G_>3) насчет шаблонов я уже говорил. да их нет, но это не критично.
Смотря что понимать под "критично". Overhead и возможные ошибки при преобразованиях типов — для меня, например, это весьма критично.

G_>>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi

).
А>>В бОльшинстве случаев интереснее hash_map. А еще нету интеллектуальных указателей, без коих много-много сложнее...
G_>Ну да. Вот это действительно беда Delphi. Даже в Яве есть набор замечательных структур
Э-э, smart pointers — это не структура данных. Это патерн, уничтожающий объект в момент, когда он становится никому более не нужным. Чаще всего реализуется путем подсчета ссылок.
G_>с добавлением/поиском/удалением за O(log n)...

А в Java та же проблема, что и в Delphi и в .NET — без generics-типов (шаблонов) невозможно создать алгоритм, специализируемый при компиляции с проверкой времени компиляции, поэтому приходится прибегать все к тому же кастованию типов. На Delphi, точно так же, как и на Java можно реализовать и slice-списки, и B-деревья, и прочие весьма эффективные (для конкретной задачи) структуры. Однако гибкости, предоставляемой шаблонами, нам не получить. Впрочем, в Java шаблоны вроде бы обещали в JDK 1.5, а в C# шаблоны будут во второй редакции языка... так что не все так мрачно.

G_>>>Далее, серьезный недостаток Delphi Pascal — отсутствие стековых объектов, все объекты — в дин. памяти и соот-но создание объекта и его уничтожение приходится делать собственноручно. Т.е. C++:
А>>Таких примеров можно привести еще очень много. Поэтому я и говорю, что все удобства в Delphi заканчиваются, когда заканчивается мышевозня...
G_>Я предпочитаю говорить о конкретных недостатках...
О конкретных недостатках правильнее говорить в контексте той или иной задачи — класса задач.

G_>>>Шаблоны бы не помешали, но вообще говоря это не must have.
А>>Это must have однозначно, потому как: валидация во время компиляции, потому как: универсальный строго типизированный код без надобности кастования типов (list<int>, list<string> ...), потому как: патерны (smartpointer, class factory, singleton и т.д. и т.д.).
G_>Шаблоны это замечательно, согласен. Кстати, они появились в Яве (1.5).
Таки появились? Замечательно.
G_>Но повторяюсь в третий раз — можно пережить и без них.
Можно, бесспорно. Живет ведь Янус (RSDN@Home) без них. И наши проекты на C# тоже живут. Тем не менее, шаблоны исключительно важны для любого современного языка.

G_>>>Вообщем, надеюсь главная мысль ясна. Дельфи — замечательная "обертка" для проекта под Windows, он легко "тянет" и маленькие, и большие проекты.
А>>Маленькие, да, тянет. Большие... — разве что у мазохистов/энтузиастов.
G_>Аргументы?
Назову один, но весьма-весьма весомый — в Delphi отсутствуют smart pointers/garbage collector.

G_>>>PS Один из отцов-основателей Delphi ушел в Microsoft разрабатывать C#, так что нетрудно заметить как отличные идеи в Delphi (скажем as и is) переползли в C#.
А>>А с чего ты взял, что эти идеи принадлежат Borland?

Кстати, ничего отличного в них не вижу. Как и невижу ничего хорошего во всевсяческих кастованиях типов (что во многих случаях есть костыль при отсутствии шаблонов).
G_>Да я не о том, что кому принадлежит. Я к тому, что .NET вобрала в себя лучшее и безусловно будет доминировать.
VB, C++, Java безусловно доминировали до создания .NET Да и сейчас, впрочем, Java и C++ доминируют.

G_>as и is — не обязательно "костыль"

G_>Простейший пример — обход контролов на форме с целью прописывания только лейблам какого-то свойства.
G_>Простой, наглядный код с as и is. (а не static_cast<label> и пр.)
А зачем в этой задаче static_cast?

В таком случае действительно удобнее было запросить у формы коллекцию этих объектов и пройтись по коллекции оператором foreach. Например, так:

foreach(Label label in MyForm.Controls["Label"]) 
{
    label.Text = label.Name;
    ...
}

... << RSDN@Home 1.1.3 stable >>

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

G_>>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi

... << RSDN@Home 1.1.3 stable >>

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

DG>1. C#
DG>2. Delphi
DG>3. Builder
DG>4. C++ + MFC
DG>5. C++ + WTL/ATL

DG>P.S. Если надо писать небольшие приложения, то я бы поставил связку C++ + WTL/ATL на 2 место.
А для средних и больших проектов пункты 2 и 3 вообще выкинуть, как нерелевантные.

... << RSDN@Home 1.1.3 stable >>

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

DG>>1. C#
DG>>2. Delphi
DG>>3. Builder
DG>>4. C++ + MFC
DG>>5. C++ + WTL/ATL

A>Я бы вот только BCB вынес на первое место т.к. он юзает и компоненты от Delphi и просто C++ либы.
В итоге получается нечто такое, что вообще использовать нельзя ни в коем случае. Даже на очень-очень малых проектах легко столкнуться с пресловутой глючностью CBuilder.
A>На счет C# на первом месте — считаю что спорно, но спорить не буду.
A>И надо еще Java куда-нибудь воткнуть, куда-нибудь наверх, у них тоже очень хороший набор библиотек.
А Java как раз рядом с C# неплохо смотрится.

... << RSDN@Home 1.1.3 stable >>

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

DG>Проблема в том, что хоть в BCB по сравнению с Delphi есть плюсы (язык C++), так есть и большие минусы:
DG>плохая поддержка стандарта C++,
Кстати, не такая уж и плохая. Она где-то на уровне между VC++ 6 и VC++ 7.

A>>На счет C# на первом месте — считаю что спорно, но спорить не буду.
DG>Но C# бесспорно лучше Delphi, вот C# и Delphi.Net будут равны,
Весьма сомнительно. Особенно в свете C# 2.
DG>или даже Delphi.Net будет лучше (за счет своих классов),
А что там особенного с ее классами и что помешает использовать "ее" классы в проектах на C#?

A>>И надо еще Java куда-нибудь воткнуть, куда-нибудь наверх, у них тоже очень хороший набор библиотек.
DG>ИМХО, на Java-е мало пишут под винды....
Много. Я бы сказал очень много. Но в основном это enterprise-level решения и outsourcing.

... << RSDN@Home 1.1.3 stable >>

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

А>>В действительности о Delphi, как таковой, можно забыть как о страшном сне. Borland ее развивать не будет. В более-менее серьезных проектах использовать Delphi, в виду убогости Object Pascal и, собственно, VCL, не рационально. Да и зачем, если есть .NET?.

AM>Могу допустить убогость VCL, но вопрос в чес убогость Object Pascal?
Delphi language? А сравните, например, с .NET-языками, C++, Java, OCaml... Благо, спецификации их доступны в Интернет.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, <Аноним>, Вы писали:

А>Языки созданы для того, чтобы на них писать — в первую очередь. Именно потому популярность у профессионалов приобрели клоны C-синтаксиса, а не Pascal, Basic или тому подобного.

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

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

Сарказ? Больше глупость. Катигоричности же тут никакой нет. Это просто мнение.

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

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

VD>>Хотя конечно чем их меньше, тем лучше. Ну, да хорошо спроектированная программа на любом языка старается их не делать. Что же касается стабильности, то тут С++ на последнем месте, так как язык не карантируем типобезопастности в рантайме. Молейшая ошибка и память испорчена...
А>Да-да, вопрос профессионального уровня.

Гарантия 100%. Доказана 20 годами применения С++. И как раз только отсуствие этого самого опыта может подвигнуть рассуждать о нем.

... << RSDN@Home 1.1.3 beta 2 >>

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

G_>Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?)

TBucketList хотя конечно я вряд ли сойду за гуру по Дельфям. Если мне не изменяет память появилась в 6-ке.

G_> и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi

).

А почему нельзя было отсортировать лист и применять бинарный поиск. Хотя конечно назвать коллекции Дельфей полноценными я бы тоже не осмелился.

G_>Далее, серьезный недостаток Delphi Pascal — отсутствие стековых объектов, все объекты — в дин. памяти и соот-но создание объекта и
G_>его уничтожение приходится делать собственноручно. Т.е. C++:

Вообще-то в дельфи есть тип object и record.

G_>{
G_> SOME_STACK stack(some_parameter);
G_> stack.push(123);
G_> ...
G_>}
G_>// stack уже автоматически уничтожен и его деструктор вызван

Так это наличие автоматического вызова деструктора/финалайзера. В Шарпе этого тоже нет. Но есть IDisposeble и инструкция using.

G_>Шаблоны бы не помешали, но вообще говоря это не must have.

Как минимум более типобезопасно. Так что уж точно не повредит.

G_>Вообщем, надеюсь главная мысль ясна. Дельфи — замечательная "обертка" для проекта под Windows, он легко "тянет" и маленькие, и большие проекты. А еще лучше он становится, если его доработать своими собственными библиотеками (хоть на C++, хоть на чем еще

. И под него удобно делать и ActiveX-ы и еще много чего другого.

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

G_>PS Один из отцов-основателей Delphi ушел в Microsoft разрабатывать C#, так что нетрудно заметить как отличные идеи в Delphi (скажем as и is) переползли в C#.

Ну, с Явы он точно больше содрал. Из Дельфи больше взято в ВыньФормс. Но это библиотека, а не язык.

G_>PPS К сожалению, Delphi конец.

Мы получим еше одно обновление Delphi 7.1, после чего будет развиваться только Delphi .NET.
G_>Король умер, да здравствует король.

А от чего же конец то? Дельфи 8 лучше 7-ки хотя бы тем что к ВЦЛ прибавилась огромная ФЦЛ дотнета. Язык стал надежнее. Решены проблемы с тем же Free.

Что так печально то?

... << RSDN@Home 1.1.3 beta 2 >>

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

G_>1. создать нормальный мап — совершенно нетривиальная задача! (ну-ка давайте-ка по памяти напишем процедурку удаления узла из красно-черного или AVL дерева, слабо?)

"Нормальные" мапы не пишутся на деревьях. Да и зачем по памяти. В гугле за пять минут можно надыбать алгоритмы. Они очень не сложне. Другое дело что размножать вручную типизированные коллекции без генерации кода не очень разумно. Хотя для одного проекта приемлемо. Не так уж много коллекций обычно в проектах.

G_>2. стандартизация — великая вещь, а так у каждого будут в проекте свои контейнеры и свои способы работы с ними и т.д., это очень плохо

А кто мешает написать публичную библиотеку? Я вообще не очень понимаю почему для Дельфи библиотек с окошками и феничками хоть завались, а с коллекциями и алгоритмами на пальцах одной руки можно перечесть.

G_>То, что STL появилась на свет и успешно существует и очень многими используется доказывает мою правоту.

Ага. А так же ее доказывает. Наличие МФЦ, АТЛ-а, буста, и других библиотек содержащих свои коллекции.

... << RSDN@Home 1.1.3 beta 2 >>

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

S>А под мап можно подогнать и Хэш таблицы и BitArray и B+ деревья и просто массив и у всех есть плюсы и минусы и своя область применения.

О! Блин, золотые слова! Вот бы ты их и в обратную сторону понимал. Вспомни свое Б+-дерево без итераторов.

... << RSDN@Home 1.1.3 beta 2 >>

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

S>> Не ошибается тот кто ничего не делает, а кривизны в стандартных библиотеках хватает выше крыши как в Delphi, Net, Java.
kuj>Можно узнать перечень "кривизны" в .NET? И что подразумевается под "выше крыши", применительно к кривизне .NET?

Она есть везде. В дотнете есть и код с багами. И не оптимальные реализации (одна сериализация чего стоит). А узнать можно почитав с недельку соотвествующий форум на этом сайте.

S>> Нет кривизны только в STL !!!!!!
kuj>Ага... Особенно в std::auto_ptr.
kuj>Задумайтесь, почему многие предпочитают заменять "стандартный" STL в VС++ на STLPort, а вместо std::auto_ptr использовать boost::shared_ptr

Блин. Ну, что за народ?! Сарказма отличить не может.

... << RSDN@Home 1.1.3 beta 2 >>

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

S> Не боись дженерики заменят шаблоны. А насчет Хэйлсбега ты зря. Можно спорить на что Net (Delph.Net,C#) похож на Java или Delphi но общего у них очень много.

А ты задумывался почему? Не потому ли что это все ОО компонентные системы RAD-разработки?

... << RSDN@Home 1.1.3 beta 2 >>

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

ST>ИМХО отказ от разделения декларации и реализации ухудшает возможности разбиения на модули гораздо больше чем в Delphi по сравнению с C++. На что у изобретателей Java есть стандартный ответ : "если правильно проектировать ...".

Хороший, кстати, ответ. Но разбиение на модули никак не связано с пре-декларациями. В том же C# 2.0 и VB.NET 2.0 будут введены средства разбиения на модули без предеклараций. Просто класс можно будет пометить как разбиваемый и положить отдельные его части в разные файлы.

Забавно что люди привыкшие к предекларациям всячески защищают этот атавизм. Правда отвыкнув и вирнувшись к нему обратно сильно матерятся и проклинают его.

Ну, да видимо это все от того, что каждый колик свое болото хвалит.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, <Аноним>, Вы писали:

А>Нет у него уже никаких перспектив. Борланд полностью отказалась от VCL в пользу .NET Стоит признать, правильно сделала.

Борланд от ВЦЛ? А это ничего что он портировал ВЦЛ под дотнет?

А>>чем у Delphi. Чего спорить, "бацанье" интерфейса у Борланда лучше чем у VC (все версии).
А>Смотрим на WinForms и забываем про VCL, как про страшный сон.

Скорее забыаем о дельфи. А если уж ты используеш дельфи то можно и не забывать.

Правда выйдет Авалон с XAML-ом и про них обоих можно будет забыть. Но годков эдак через 5.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, <Аноним>, Вы писали:

А>перегрузку операторов не умеет, функции с переменным количеством параметров не умеет.

Отстал ты от жизни.

А>В итоге ни тебе патернов более-менее сложных (хотя бы интеллектуальных указателей, без которых сейчас никуда),

Опять отстал. В дельфи 8 это все уже не нужно.

А> ни тебе универсальных структур, специализируемых через шаблон на этапе компиляции.

Ну, если не смотреть на скорость, то в есть ОО-решения. Они даже покомпактнее выходят.

А> Да чего только стоит возможность инстанцирования (!) абстрактного класса!

Потому на Делфи дальше пользовательского интерфейса не уедешь.

Ну, это снение человека никогда на ней не писавшего. Все на ней можно сделать. Много конечто чего нет, но не критично это все. За то есть другие фичи. Поддержка компонентнго подхода, КОМ-а. А теперь и весь дотнет.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, <Аноним>, Вы писали:

А>Функции с переменным числом параметров?...

Про этот багадром в плюсах лучше молчать. Как-то умнее выглядеть при этом начинаешь.

А вообще в 8-ке много чего появилось. Разве что шаблонов нет.

... << RSDN@Home 1.1.3 beta 2 >>

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

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

S>> Не боись дженерики заменят шаблоны. А насчет Хэйлсбега ты зря. Можно спорить на что Net (Delph.Net,C#) похож на Java или Delphi но общего у них очень много.

VD>А ты задумывался почему? Не потому ли что это все ОО компонентные системы RAD-разработки?
Многие RAD сти не нужны, а нужна единая иерархия классов,RTTI, метаклассы итд.
В С++ другие задачи прежде всего скорость в угоду гибкости. От виртуальныех методов шарахаются как черт от ладана, поэтому шаблоны и преобладают в этом языке. Причем RTTI можно подключать или отключать по усмотрению итд. При стройной же иерархии легче строить сложные системы, а учитывая современные мощности компьютеров на скорость уже давно забили.
И какие радости в С# если ты используешь консоль???? И много ли используешь встроенную сериализацию???
Компонентнось в этих языках всего лишь одно из достоинств единой иерархии классов.

... << RSDN@Home 1.1.0 stable >>

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

DG>>Но C# бесспорно лучше Delphi, вот C# и Delphi.Net будут равны,
kuj>Весьма сомнительно. Особенно в свете C# 2.
DG>>или даже Delphi.Net будет лучше (за счет своих классов),
Поддержка Delphi.Net фремворк 2 будет полной.
http://www.rsdn.ru/forum/Message.aspx?mid=606662&only=1

... << RSDN@Home 1.1.0 stable >>

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

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

А>>>В действительности о Delphi, как таковой, можно забыть как о страшном сне. Borland ее развивать не будет. В более-менее серьезных проектах использовать Delphi, в виду убогости Object Pascal и, собственно, VCL, не рационально. Да и зачем, если есть .NET?.

AM>>Могу допустить убогость VCL, но вопрос в чес убогость Object Pascal?
kuj>Delphi language? А сравните, например, с .NET-языками, C++, Java, OCaml... Благо, спецификации их доступны в Интернет.
Delphi.Net language?
А если серьезно все проблемы в поверхностном знании этого могучего языка. Помню было сравнение языков в "Программисте" при этом много ляпусов было допущено и Виртовские языки весьма неплохо смотрелись а победила там ADA.

... << RSDN@Home 1.1.0 stable >>

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

VD>>А ты задумывался почему? Не потому ли что это все ОО компонентные системы RAD-разработки?
S> Многие RAD сти не нужны, а нужна единая иерархия классов,RTTI, метаклассы итд.

Интересно к чему это ты сказал? И почему ты считаешь, что именно ты знаешь, что нужно, а что нет?

S> В С++ другие задачи прежде всего скорость в угоду гибкости.

Может прежде чем делать такие заявления хоть чуть-чуть изучить С++? А ведь смешно выглядит.

S> От виртуальныех методов шарахаются как черт от ладана, поэтому шаблоны и преобладают в этом языке.

Виртуальные методы в С++ ничем не хуже чем в Дельфи или еще где-то. И никто от них не шархается. Просто когда у тебя есть два пути решения одной и той же задачи, то (если ты конечно разумный человек) всегда выбереш самый просто, безопасный и быстрый спостоб. Вот шаблоны за частую и явлются таким выходом.

S> Причем RTTI можно подключать или отключать по усмотрению итд. При стройной же иерархии легче строить сложные системы, а учитывая современные мощности компьютеров на скорость уже давно забили.

И много ты сложных систем написал, что делаешь такие заявления?

S> И какие радости в С# если ты используешь консоль????

Все. Нет разницы коносльное приложение или куевое. Скорость разработки все равно выше.

S> И много ли используешь встроенную сериализацию???

А она то каким боком тут? Я ее вообще стараюсь не использовать.

S> Компонентнось в этих языках всего лишь одно из достоинств единой иерархии классов.

Полнейшая глупость. Компонентность вообще не зависит не от наличия иерархии не от классов. В КОМ небыло ни иерархии, ни классов в полном понимании этого слова, а компонентность была.

... << RSDN@Home 1.1.3 beta 2 >>

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

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

VD>>>А ты задумывался почему? Не потому ли что это все ОО компонентные системы RAD-разработки?
S>> Многие RAD сти не нужны, а нужна единая иерархия классов,RTTI, метаклассы итд.

VD>Интересно к чему это ты сказал? И почему ты считаешь, что именно ты знаешь, что нужно, а что нет?
Delphi, Net, Ява единая иерархия классов от базового.

S>> В С++ другие задачи прежде всего скорость в угоду гибкости.

VD>Может прежде чем делать такие заявления хоть чуть-чуть изучить С++? А ведь смешно выглядит.
Ну да и почему же шаблоны являютс оотличительной частью С++???

S>> От виртуальныех методов шарахаются как черт от ладана, поэтому шаблоны и преобладают в этом языке.

VD>Виртуальные методы в С++ ничем не хуже чем в Дельфи или еще где-то. И никто от них не шархается. Просто когда у тебя есть два пути решения одной и той же задачи, то (если ты конечно разумный человек) всегда выбереш самый просто, безопасный и быстрый спостоб. Вот шаблоны за частую и явлются таким выходом.
Для мелких задач это нормально. Меня всегда удивляет почему это в С++ нет таких библиотек как Delphi, Net, Ява ?????
В чем проблема???? Или платформонезависимость мешает.
S>> Причем RTTI можно подключать или отключать по усмотрению итд. При стройной же иерархии легче строить сложные системы, а учитывая современные мощности компьютеров на скорость уже давно забили.

VD>И много ты сложных систем написал, что делаешь такие заявления?
А ты??? И почему это Net и Ява сделали ставку на стройную иерархию????

S>> И какие радости в С# если ты используешь консоль????

VD>Все. Нет разницы коносльное приложение или куевое. Скорость разработки все равно выше.
За счет чего??? Может за счет огромного количества классов и продуманной иерархии и имплементации интерфейсов????
Тогда в чем проблемы C++.
S>> И много ли используешь встроенную сериализацию???

VD>А она то каким боком тут? Я ее вообще стараюсь не использовать.
Компонентность подразымевает прежде всего Persistent, запоминание состояния. Которое возможно в том числе и через сериализацию и

S>> Компонентнось в этих языках всего лишь одно из достоинств единой иерархии классов.

VD>Полнейшая глупость. Компонентность вообще не зависит не от наличия иерархии не от классов. В КОМ небыло ни иерархии, ни классов в полном понимании этого слова, а компонентность была.
Которая базируется на на определенных интерфейсах может тебе их всех перечислить, и которые есть и в Net??????
А что такой интерфейс??? Не абстрактный ли виртуальный клас????? И наследование интерфейсов к иерархии не имеет никакого отношения????
А то что имплементируют их в классах тоже никакого отношения не имеет???? И получить тот или иной интерфейс через QueryInterface тоже никакого отношения к иерархии не имеет????
Причем в Delphi из любого контрола легко сделать Олеконтрол

... << RSDN@Home 1.1.0 stable >>

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

S> Delphi, Net, Ява единая иерархия классов от базового.

А MFC — нет?

S>>> В С++ другие задачи прежде всего скорость в угоду гибкости.

VD>>Может прежде чем делать такие заявления хоть чуть-чуть изучить С++? А ведь смешно выглядит.
S> Ну да и почему же шаблоны являютс оотличительной частью С++???

Ты уверен, что отвечаешь на заданный вопрос? И вообще, вопросом на вопрос не хорошо как то...

S> Для мелких задач это нормально. Меня всегда удивляет почему это в С++ нет таких библиотек как Delphi, Net, Ява ?????

А тебя не удивляют рассуждения человека вообще не знающего С++ о библиотеках в ней?

Сравнивать же библиотеки Дельфи с библиотеками С++ лучше не надо. По количеству библиотек плюса намного в пререди. Другое дело, что VCL намного проще в применении из-за ориентации на компонентные технологии и RAD. Ну, да они и в СппБилдере доступна.

S> В чем проблема???? Или платформонезависимость мешает.

Отсуствие знания предмета спора мешает.

VD>>И много ты сложных систем написал, что делаешь такие заявления?
S> А ты??? И почему это Net и Ява сделали ставку на стройную иерархию????

Четыре штуки . Причем на плюсах из них две. Правда конечно не все целиком, но руку прикладывал и проектировал.

S> За счет чего??? Может за счет огромного количества классов и продуманной иерархии и имплементации интерфейсов????

Скорее из-за интели-сенс, броузера классов, и т.п. Но и из-за простоты и удобства библиотек конечно же. Однако библиотеки тоже не относятся к ГУИ.

S> Тогда в чем проблемы C++.

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

S> Компонентность подразымевает прежде всего Persistent, запоминание состояния. Которое возможно в том числе и через сериализацию и

Так твоей persistents при разработке достигаетя сериализацией в код. Которая вооще не важно сколько времени отнимает, так как происходит в дизайнтайме. В рантайме же просто выполняется код. И его скорость оптимальна.

VD>>В КОМ небыло ни иерархии, ни классов в полном понимании этого слова, а компонентность была.
S> Которая базируется на на определенных интерфейсах может тебе их всех перечислить, и которые есть и в Net??????

Пожалуйста: IUncnown, IDispatch.

S> А что такой интерфейс??? Не абстрактный ли виртуальный клас?????

В КОМ и дотнете эти понятия очень похожи. А в общем случае это просто набор публичных методов.

S> И наследование интерфейсов к иерархии не имеет никакого отношения????

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

S> А то что имплементируют их в классах тоже никакого отношения не имеет????

К компонентности то? Конечно никакого. Это детали реализации.

S> И получить тот или иной интерфейс через QueryInterface тоже никакого отношения к иерархии не имеет????

Это детали самого КОМ-а.

S> Причем в Delphi из любого контрола легко сделать Олеконтрол

Здорово. Это видимо тоже доказывает, что "Компонентнось в этих языках всего лишь одно из достоинств единой иерархии классов."?

... << RSDN@Home 1.1.3 beta 2 >>

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

VD>В сложности языка. Например, при наличии моря библиотек все же не удается так быстро и просто задейсвовать нужный класс. Та же хэш-таблица требует много обвязочного кода (это только в Яве и дотнете хэш автоматом вычисляется).
За счет того, что эти операции были введены в базовый класс и его продуманная структура. Хотя в Delphi же все пляшет вокруг TObject,
как выделение памяти через виртуальный статический метод NewInstance и еще кучи методов происанных в VMT. И на этом базовом объекте очень легко строить любые иерархии. В том числе и уход от множественного наследования обусловлен сложностью поддержания таких структур.

S>> Компонентность подразымевает прежде всего Persistent, запоминание состояния. Которое возможно в том числе и через сериализацию и

VD>Так твоей persistents при разработке достигаетя сериализацией в код. Которая вооще не важно сколько времени отнимает, так как происходит в дизайнтайме. В рантайме же просто выполняется код. И его скорость оптимальна.
Я же написал в том,числе. А как например с большими двоичными данными его тоже в Base64 запихивать или лучше в ресурсы закинуть.
VD>>>В КОМ небыло ни иерархии, ни классов в полном понимании этого слова, а компонентность была.
S>> Которая базируется на на определенных интерфейсах может тебе их всех перечислить, и которые есть и в Net??????

VD>Пожалуйста: IUncnown, IDispatch.
IUnknown, IOleClientSite,
IOleControlSite, IOleInPlaceSite, IOleInPlaceFrame, IDispatch,
IPropertyNotifySink, ISimpleFrameSite,IAdviseSink, IAdviseSink2,
IDataObject итд

S>> А что такой интерфейс??? Не абстрактный ли виртуальный клас?????

VD>В КОМ и дотнете эти понятия очень похожи. А в общем случае это просто набор публичных методов.

S>> И наследование интерфейсов к иерархии не имеет никакого отношения????

VD>А им никто почти не пользуется. Весь кайф интерфейсов в том, что они позволяют создавать составные абстракции.
Ну да методы IUnknown нигде не используются. Опять же в основе любого интерфейса лежит базовый интерфейс.
К Net это не имеет отношения т.к. там другой механизм (и в чемто это даже и плохо, т.к. иногда нужно запросить некий интерфейс который имплементирует объект являющийся полем объекта).

S>> А то что имплементируют их в классах тоже никакого отношения не имеет????

В свое время можно было легко обмениваться виртуальными объектами между С++ и Delphi т.к. последовательность описания методов однообразно ложилась в VMT. В COM тоже самое.
VD>К компонентности то? Конечно никакого. Это детали реализации.
За то к набору поддерживаемых интерфейсов, получаемые через ...

S>> И получить тот или иной интерфейс через QueryInterface тоже никакого отношения к иерархии не имеет????

VD>Это детали самого КОМ-а.

S>> Причем в Delphi из любого контрола легко сделать Олеконтрол

VD>Здорово. Это видимо тоже доказывает, что "Компонентнось в этих языках всего лишь одно из достоинств единой иерархии классов."?

Конечно!!!!! Плюс в Delphi и Яве большую помощь оказывают метаклассы.
Сделай в Delphi перегрузку методов и шаблоны или кодогенерацию то ....

... << RSDN@Home 1.1.0 stable >>

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

S> За счет того, что эти операции были введены в базовый класс и его продуманная структура. Хотя в Delphi же все пляшет вокруг TObject,

Э батенька. Ни Дельфи, ни С++ не позволяют трактовать встроенные типы как классы. Тут уже нужен подход на уровне языка и среды исполнения.

VD>>Пожалуйста: IUncnown, IDispatch.

S>IOleClientSite,
S> IOleControlSite, IOleInPlaceSite, IOleInPlaceFrame, IDispatch,
S> IPropertyNotifySink, ISimpleFrameSite,IAdviseSink, IAdviseSink2,
S> IDataObject итд

Это не есть базовые интерфейсы. Эдак можно все созданные на дотнете интерфейсы к дотнету приписать.

К компонентной модели это точно не относится. Ты еще не забыл по какому поводу ты высказывался?

S> Ну да методы IUnknown нигде не используются. Опять же в основе любого интерфейса лежит базовый интерфейс.

Считай что IUnknown — это внутрення реализация ком-а на С++. В дотнете без нее спокойно обошлись. В Дельфи ее тоже почти не видно.

S> К Net это не имеет отношения т.к. там другой механизм (и в чемто это даже и плохо, т.к. иногда нужно запросить некий интерфейс который имплементирует объект являющийся полем объекта).

Реализуй механизм приведения типов...

S>>> А то что имплементируют их в классах тоже никакого отношения не имеет????

S> В свое время можно было легко обмениваться виртуальными объектами между С++ и Delphi т.к. последовательность описания методов однообразно ложилась в VMT. В COM тоже самое.

Это ты сам с собой споришь?

Что же касается VMT, то для КОМ-а была выбрана реализация С++ Дельфи ее просто стибрило для совместимости. Но VMT в С++ значительно сложнее из-за множественного наследования (МН). Именно из-за этого в КОМ-е было запрещено МН для интерфейсов.

S>>> Причем в Delphi из любого контрола легко сделать Олеконтрол

VD>>Здорово. Это видимо тоже доказывает, что "Компонентнось в этих языках всего лишь одно из достоинств единой иерархии классов."?

S> Конечно!!!!! Плюс в Delphi и Яве большую помощь оказывают метаклассы.

О, блин. Еще и какие-то метаклассы припер. Кстати, в Яве такой же рефлекшен как в дотнете. Так что к ней свои метаклассы лучше не прилетай.

S> Сделай в Delphi перегрузку методов и шаблоны или кодогенерацию то ....

Что, то?

В общем, фигню какую-то говоришь. Единая иерархия никакого отношения к поддержке комонентности н имеет.

... << RSDN@Home 1.1.3 beta 2 >>

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

S> В свое время можно было легко обмениваться виртуальными объектами между С++ и Delphi т.к. последовательность описания методов однообразно ложилась в VMT. В COM тоже самое.

AFAIK, в качестве COM-овских интерфейсов была взята уже готовая реализация VMT из MS C++. А Delphi изначально делалась с оглядкой на COM. Так что совместимость по формату VMT между Delphi и C++ — это заслуга именно COM

By the grace of God Almighty
And the pressures of a marketplace
The human race has civilized itself
It's a miracle

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

А>>>>В действительности о Delphi, как таковой, можно забыть как о страшном сне. Borland ее развивать не будет. В более-менее серьезных проектах использовать Delphi, в виду убогости Object Pascal и, собственно, VCL, не рационально. Да и зачем, если есть .NET?.

AM>>>Могу допустить убогость VCL, но вопрос в чес убогость Object Pascal?
kuj>>Delphi language? А сравните, например, с .NET-языками, C++, Java, OCaml... Благо, спецификации их доступны в Интернет.
S> Delphi.Net language?
Да особо без разницы. .NET-языки обязаны отвечать определенным требованиям, поэтому существенных различий между ними нету.
S> А если серьезно все проблемы в поверхностном знании этого могучего языка. Помню было сравнение языков в "Программисте" при этом много
Э-э, Delphi language могучий язык? Не смешите мои тапочки!

S> ляпусов было допущено и Виртовские языки весьма неплохо смотрелись а победила там ADA.
Э-э, сколько лет назад это было? По каким критериям сравнивали? Для каких задачей? Хотите, чтоб я вас убедил, что есть класс задач, где оптимальным выбором станет не процедурный, а вполне себе функциональный OCaml, например? А ежели ограничиться сравнением C++/.NET семейство vs Delphi Language, то и тут должно быть все очевидно. Нет?

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, <Аноним>, Вы писали:

А>MS официально отказалась от COM в пользу .NET (которая с лихвой покрывает функциональность COM)

Увы пока нет. Многие сервисы, существующие в СОМ+ пока еще либо недоступны дотнетным объектам без использования СОМ, либо убоги.

... << RSDN@Home 1.1.3 beta 2 (Win32NT 5.1.2600.0) >>

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

S>> И много ли используешь встроенную сериализацию???

VD>А она то каким боком тут? Я ее вообще стараюсь не использовать.

Гы гы, наивные, не используют они

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

... << RSDN@Home 1.1.3 beta 2 (Win32NT 5.1.2600.0) >>

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

G_>>>А Дельфи замечательно переваривает большие проекты (скажем, сейчас у меня в проекте 118 юнитов из них 58 форм) — _никаких_ _тормозов_. Это замечательно.
А>>По секрету скажу, что 58 форм и 118 юнитов — это *не*большой проект. Ну разве что средний размер одного юнита у тебя — 1MB

G_>Ну все относительно конечно

Чего, пиписьками меряемся? Легко

. В янусе полтора мега плюсовых и шарповских исходников (при том что эти языки лаконичнее паскаля). При том он ни в коем разе не является большим проектом.

... << RSDN@Home 1.1.3 beta 2 (Win32NT 5.1.2600.0) >>

Здравствуйте, <Аноним>, Вы писали:

VD>>Без приведения типов и на С++ нельзя.
А>В действительности можно, если сильно захотеть. Вопрос в профессиональном опыте, коего Вам, судя по всему, не хватает. Не обессудьте.
VD>>Хотя конечно чем их меньше, тем лучше. Ну, да хорошо спроектированная программа на любом языка старается их не делать. Что же касается стабильности, то тут С++ на последнем месте, так как язык не карантируем типобезопастности в рантайме. Молейшая ошибка и память испорчена...
А>Да-да, вопрос профессионального уровня.

Рекомендую ознакомится с правилами форумов и впредь больше их не нарушать.

... << RSDN@Home 1.1.3 beta 2 (Win32NT 5.1.2600.0) >>

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

AVK>Гы гы, наивные, не используют они

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

Ну, укажи мне на использование стандартной сериализации в том же R#-е. Проект вроде не маленький.

... << RSDN@Home 1.1.3 beta 2 >>

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

AVK>Чего, пиписьками меряемся? Легко

Ну, уже не маленький. Правда плюсовых там кил 150, не более.

... << RSDN@Home 1.1.3 beta 2 >>

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

VD>Ну, укажи мне на использование стандартной сериализации в том же R#-е. Проект вроде не маленький.

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

... << RSDN@Home 1.1.3 beta 2 (Win32NT 5.1.2600.0) >>

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

AVK>>Чего, пиписьками меряемся? Легко

VD>Ну, уже не маленький.

Да чего там большого? Чистого времени не более половины человекогода.

VD> Правда плюсовых там кил 150, не более.

72K

... << RSDN@Home 1.1.3 beta 2 (Win32NT 5.1.2600.0) >>

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

VD>В общем, фигню какую-то говоришь. Единая иерархия никакого отношения к поддержке комонентности н имеет.
Самое прямое. Если в C++ класс ничем не отличается от структуры и лкгко можно дать ссылку объект как в куче так и в стеке.
Кроме того при выделении памяти под объект используется свой манагер памяти (В Net и Яве GC но тоже единый МП).
Кстати при освобождении памяти из выделенной через HeapAlloc в 10 раз медленне чем в МП Delphi.
Единая иерархия дает достаточно просто выделять память иницализироват (в том числе и поддерживаемые интерфейсы http://www.rsdn.ru/Forum/Message.aspx?mid=527260&only=1 ) а так же и освобождение памяти.
Мктаклассы (или рефлексия просто метаклассы быстрее и типизированные а в Яве Clas.CreateInstance к рефлексии никакого отношения не имеет),
позволяют лего создавать объекты (constructor Create(AOwner: TComponent); virtual

регистрировать метаклассы

         procedure RegisterClass(AClass: TPersistentClass);
begin
  RegGroups.Lock;
  try
    while not RegGroups.Registered(AClass) do
    begin
      RegGroups.RegisterClass(AClass);
      if AClass = TPersistent then Break;
      AClass := TPersistentClass(AClass.ClassParent);
    end;
  finally
    RegGroups.Unlock;
  end;
end;

 Получать метаклассы
 
[pascal]
 function GetClass(const AClassName: string): TPersistentClass;
begin
  RegGroups.Lock;
  try
    Result := RegGroups.GetClass(AClassName);
  finally
    RegGroups.Unlock;
  end;
end;
[/pascal]


 


[pascal]
 procedure CreateComponent;
  var
    ComponentClass: TComponentClass;
  begin
    try
      ComponentClass := FindComponentClass(CompClass);
      Result := nil;
      if Assigned(FOnCreateComponent) then
        FOnCreateComponent(Self, ComponentClass, Result);
      if Result = nil then
      begin
        Result := TComponent(ComponentClass.NewInstance);
        if ffInline in Flags then
        begin
          Include(Result.FComponentState, csLoading);
          Include(Result.FComponentState, csInline);
        end;
        try
          Result.Create(Owner);
        except
          Result := nil;
          raise;
        end;
      end;
      Include(Result.FComponentState, csLoading);
    except
      if not Recover(Result) then raise;
    end;
  end;
[/pascal]

и загружать персистентные данные и все это встроено в язык.

function InitInheritedComponent(Instance: TComponent; RootAncestor: TClass): Boolean;

  function InitComponent(ClassType: TClass): Boolean;
  begin
    Result := False;
    if (ClassType = TComponent) or (ClassType = RootAncestor) then Exit;
    Result := InitComponent(ClassType.ClassParent);
    Result := InternalReadComponentRes(ClassType.ClassName, FindResourceHInstance(
      FindClassHInstance(ClassType)), Instance) or Result;
  end;

var
  LocalizeLoading: Boolean;
begin
  GlobalNameSpace.BeginWrite;  // hold lock across all ancestor loads (performance)
  try
    LocalizeLoading := (Instance.ComponentState * [csInline, csLoading]) = [];
    if LocalizeLoading then BeginGlobalLoading;  // push new loadlist onto stack
    try
      Result := InitComponent(Instance.ClassType);
      if LocalizeLoading then NotifyGlobalLoading;  // call Loaded
    finally
      if LocalizeLoading then EndGlobalLoading;  // pop loadlist off stack
    end;
  finally
    GlobalNameSpace.EndWrite;
  end;
end;

function InitComponentRes(const ResName: string; Instance: TComponent): Boolean;
begin
  Result := InternalReadComponentRes(ResName, FindResourceHInstance(
    FindClassHInstance(Instance.ClassType)), Instance);
end;

function ReadComponentRes(const ResName: string; Instance: TComponent): TComponent;
var
  HInstance: THandle;
begin
  if Instance <> nil then
    HInstance := FindResourceHInstance(FindClassHInstance(Instance.ClassType))
  else HInstance := 0;
  if InternalReadComponentRes(ResName, HInstance, Instance) then
    Result := Instance else
    raise EResNotFound.CreateFmt(SResNotFound, [ResName]);
end;

function ReadComponentResEx(HInstance: THandle; const ResName: string): TComponent;
var
  Instance: TComponent;
begin
  Instance := nil;
  if InternalReadComponentRes(ResName, HInstance, Instance) then
    Result := Instance else
    raise EResNotFound.CreateFmt(SResNotFound, [ResName]);
end;

function ReadComponentResFile(const FileName: string; Instance: TComponent): TComponent;
var
  Stream: TStream;
begin
  Stream := TFileStream.Create(FileName, fmOpenRead or fmShareDenyWrite);
  try
    Result := Stream.ReadComponentRes(Instance);
  finally
    Stream.Free;
  end;
end;

Так в Delphi просто был сделан неиспользуемым packed Class , который мог был по сути аналогом класса в C++, как из нет в Net и Яве.
Единообразие упрощает проектирование среды и поддержки компанентности на уровне компилятора.
Конечно все это можно сделать и в С++ но ручками

... << RSDN@Home 1.1.0 stable >>

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

kuj>Э-э, сколько лет назад это было? По каким критериям сравнивали? Для каких задачей? Хотите, чтоб я вас убедил, что есть класс задач, где оптимальным выбором станет не процедурный, а вполне себе функциональный OCaml, например? А ежели ограничиться сравнением C++/.NET семейство vs Delphi Language, то и тут должно быть все очевидно. Нет?
Ага наверное логичнее сравнивать Delphi/Net/Java vc C++. Так как у Net и у Delphi на много больше схожего и дельфисты в Net и Яве как рыбы в воде, чего не скажешь о сишниках.

... << RSDN@Home 1.1.0 stable >>

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

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

S>> В свое время можно было легко обмениваться виртуальными объектами между С++ и Delphi т.к. последовательность описания методов однообразно ложилась в VMT. В COM тоже самое.

SC>AFAIK, в качестве COM-овских интерфейсов была взята уже готовая реализация VMT из MS C++. А Delphi изначально делалась с оглядкой на COM. Так что совместимость по формату VMT между Delphi и C++ — это заслуга именно COM

Разговор не о том что первее, а о сущности интерфейсоа как классов, наследовании и принципам ООП.
А то что M$ устанавливает правила игры, в том числе и на Васике ничего удивительного.

... << RSDN@Home 1.1.0 stable >>

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

VD>Без приведения типов и на С++ нельзя. Хотя конечно чем их меньше, тем лучше. Ну, да хорошо спроектированная программа на любом языка старается их не делать. Что же касается стабильности, то тут С++ на последнем месте, так как язык не карантируем типобезопастности в рантайме. Молейшая ошибка и память испорчена...

А зачем допускать ошибки?! Ошибки должны быть устранены в процессе отладки и тестирования. А по стабильности C++ как раз на первом месте. Хотя, настоящий художник может сделать кистью шедевр, а неуч только загадит холст...

... << RSDN@Home 1.1.3 stable >>

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

AVK>Ну на самом деле не такой уж большой,

Да, уже приличный.

AVK> но пожалуйста. Помнится ты там хотел сборки в отдельный домен грузить, так общение между доменами, оно того, через BinaryFormatter.

Т.е. нет все же пока?

Думаю возможно множество проектов в которых не будет нужна стандартная сериализациия или ее там столько что она ни на что не влияет.

... << RSDN@Home 1.1.3 beta 2 >>

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

AVK>> но пожалуйста. Помнится ты там хотел сборки в отдельный домен грузить, так общение между доменами, оно того, через BinaryFormatter.

VD>Т.е. нет все же пока?

Ну так и проект пока что далек от завершения.

VD>Думаю возможно множество проектов в которых не будет нужна стандартная сериализациия или ее там столько что она ни на что не влияет.

Может и возможно, но пока что в реальности мне такого проекта приличных размеров не встречалось.

... << RSDN@Home 1.1.3 stable >>

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

S> Ага наверное логичнее сравнивать Delphi/Net/Java vc C++. Так как у Net и у Delphi на много больше схожего и дельфисты в Net и Яве как рыбы в воде,

Судя по вопросам в форуме что то не очень заметно.

P.S. — как человек, который хорошо знает первых три и довольно неплохо последний смею тебя заверить — Дельфи значительно ближе к С++ нежели к дотнету или джаве.

... << RSDN@Home 1.1.3 stable >>

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

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

S>> Ага наверное логичнее сравнивать Delphi/Net/Java vc C++. Так как у Net и у Delphi на много больше схожего и дельфисты в Net и Яве как рыбы в воде,

AVK>Судя по вопросам в форуме что то не очень заметно.

AVK>P.S. — как человек, который хорошо знает первых три и довольно неплохо последний смею тебя заверить — Дельфи значительно ближе к С++ нежели к дотнету или джаве.
Смотрим Delphi.Net совместимость с нативной версией 95%. Какой язык еще может позволить такой безболзненный переход ?????
Сколько мучаются с С++ ????

... << RSDN@Home 1.1.0 stable >>

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

kuj>>Э-э, сколько лет назад это было? По каким критериям сравнивали? Для каких задачей? Хотите, чтоб я вас убедил, что есть класс задач, где оптимальным выбором станет не процедурный, а вполне себе функциональный OCaml, например? А ежели ограничиться сравнением C++/.NET семейство vs Delphi Language, то и тут должно быть все очевидно. Нет?
S> Ага наверное логичнее сравнивать Delphi/Net/Java vc C++. Так как у Net и у Delphi на много больше схожего
Схожего не так уж и много. Коллекции, атрибуты, пространства имен, делегаты, множественное интерфейсное наследование, перегрузка операторов, автоматическое управление памятью, сама по себе компонентная модель и многое другое в .NET пришли отнюдь не из Delphi...
S>и дельфисты в Net и Яве как рыбы в воде, чего не скажешь о сишниках.
Я вот никогда не был "дельфистом", однако, в .NET без проблем ориентируюсь. Дельфисту все же сложнее будет, т.к. ему не известны такие понятия как, например, пространство имен (C++), построение "цепочек" делегатов (C++, мультиметод), атрибуты (C++, атрибутивный COM в ATL)...

... << RSDN@Home 1.1.3 stable >>

kuj>Я вот никогда не был "дельфистом", однако, в .NET без проблем ориентируюсь. Дельфисту все же сложнее будет, т.к. ему не известны такие понятия как, например, пространство имен (C++), построение "цепочек" делегатов (C++, мультиметод), атрибуты (C++, атрибутивный COM в ATL)...

И что с этого. ИМХО, в этом не так сложно разобраться если потребуется.

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

S> Смотрим Delphi.Net совместимость с нативной версией 95%. Какой язык еще может позволить такой безболзненный переход ?????

Практически любой.

... << RSDN@Home 1.1.3 stable >>

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

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

S>> Смотрим Delphi.Net совместимость с нативной версией 95%. Какой язык еще может позволить такой безболзненный переход ?????

AVK>Практически любой.
Хорошо С++ . Манагед и инманагед сильно отличаются. Васик.Нет практически совершенно другой язык.Смалталк тоже практически многое потерял.
В Delphi появилась только перегрузка операторов, и статические переменные, аттрибуты , ЖЦ, динамическая компиляция и все, остальное метаданные и другие примочки только расширение уже имеющегося. Виртуальные статические методы остались, как работа с динамическими массивами (строками) поддержка интерфейсов итд. Компонентная модель практически осталась старая. Тот кто не увлекался указателями практически безболезненно переносят все приложения, что не скажешь о других языках.

... << RSDN@Home 1.1.0 stable >>

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

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

kuj>>>Э-э, сколько лет назад это было? По каким критериям сравнивали? Для каких задачей? Хотите, чтоб я вас убедил, что есть класс задач, где оптимальным выбором станет не процедурный, а вполне себе функциональный OCaml, например? А ежели ограничиться сравнением C++/.NET семейство vs Delphi Language, то и тут должно быть все очевидно. Нет?
S>> Ага наверное логичнее сравнивать Delphi/Net/Java vc C++. Так как у Net и у Delphi на много больше схожего
kuj>Схожего не так уж и много. Коллекции, атрибуты, пространства имен, делегаты, множественное интерфейсное наследование, перегрузка операторов, автоматическое управление памятью, сама по себе компонентная модель и многое другое в .NET пришли отнюдь не из Delphi...
Да уж коллекции в Net от дельфевых мало отличаются, с дженериками разобрался за пару дней, делегаты они же TMethod, TProc=procedure of object, или TProc=procedure; и массивы процедурных типов применяется повсеместно, множественное интерфейсное наследование постоянно применяется. Несколько примеров
TComponent = class(TPersistent, IInterface, IInterfaceComponentReference)
TOleControl = class(TWinControl, IUnknown, IOleClientSite,
IOleControlSite, IOleInPlaceSite, IOleInPlaceFrame, IDispatch,
IPropertyNotifySink, ISimpleFrameSite)
S>>и дельфисты в Net и Яве как рыбы в воде, чего не скажешь о сишниках.
kuj>Я вот никогда не был "дельфистом", однако, в .NET без проблем ориентируюсь. Дельфисту все же сложнее будет, т.к. ему не известны такие понятия как, например, пространство имен (C++), построение "цепочек" делегатов (C++, мультиметод), атрибуты (C++, атрибутивный COM в ATL)...

Модульность перекрывает эти понятия. В Delphi Net модульность расширена . Аттрибуты в Net это многоранное понятие относящееся как к метаданным так и к дерективам компиляции.
Плюс добавим сюда Хэйлсберга (в том числе создателя Turbo Pascal и Delphi) . Как он мучился (мучается) с сишниками, то многое хорошее что есть в Delphi (метаклассы, BeforeConstruction,AfterConstruction, вызов конструктора предка в любом месте, Implements (реализция интерфейсов объектом являющегося полем класса) итд) не было применено в Net по большей степени из-за костности мышления сишников и явистов.

... << RSDN@Home 1.1.0 stable >>

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

S> Плюс добавим сюда Хэйлсберга (в том числе создателя Turbo Pascal и Delphi) . Как он мучился (мучается) с сишниками, то многое хорошее что есть в Delphi (метаклассы, BeforeConstruction,AfterConstruction, вызов конструктора предка в любом месте, Implements (реализция интерфейсов объектом являющегося полем класса) итд) не было применено в Net по большей степени из-за костности мышления сишников и явистов.

Как то у тебя не стыкуется — разрабатывал Хейлсберг, но нет из-за глупых сишников. Сдается мне это у тебя косность мышления, а не у сишников.

... << RSDN@Home 1.1.3 stable >>

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

AVK>>Практически любой.
S> Хорошо С++ . Манагед и инманагед сильно отличаются.

Не сильнее чем Дельфи 7 от Дельфи 8.

S> В Delphi появилась только перегрузка операторов, и статические переменные, аттрибуты , ЖЦ, динамическая компиляция и все, остальное метаданные и другие примочки только расширение уже имеющегося.

И это ты считаешь мало?

Полязыка переделали. В С++/CLI и то изменений поменьше будет, не говоря уж об МС++.

S>Тот кто не увлекался указателями практически безболезненно переносят все приложения, что не скажешь о других языках.

А Quake вот, если верить МС, за три дня перенесли.

... << RSDN@Home 1.1.3 stable >>

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

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

S>> Плюс добавим сюда Хэйлсберга (в том числе создателя Turbo Pascal и Delphi) . Как он мучился (мучается) с сишниками, то многое хорошее что есть в Delphi (метаклассы, BeforeConstruction,AfterConstruction, вызов конструктора предка в любом месте, Implements (реализция интерфейсов объектом являющегося полем класса) итд) не было применено в Net по большей степени из-за костности мышления сишников и явистов.

AVK>Как то у тебя не стыкуется — разрабатывал Хейлсберг, но нет из-за глупых сишников. Сдается мне это у тебя косность мышления, а не у сишников.
Дык не дают свободу творчества. В другой лагерь перешел однако. С волками жить по волчьи выть.

... << RSDN@Home 1.1.0 stable >>

Полязыка переделали. В С++/CLI и то изменений поменьше будет, не говоря уж об МС++.

S>>Тот кто не увлекался указателями практически безболезненно переносят все приложения, что не скажешь о других языках.

AVK>А Quake вот, если верить МС, за три дня перенесли.
И много в Quake нетовских примочек???? Компоненты там разные интерфейсы динамические массивы, IsAssignableFrom, метаклассы итд и 100% unsafe код!!!

... << RSDN@Home 1.1.0 stable >>

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

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

AVK>>>Практически любой.
S>> Хорошо С++ . Манагед и инманагед сильно отличаются.

AVK>Не сильнее чем Дельфи 7 от Дельфи 8.

S>> В Delphi появилась только перегрузка операторов, и статические переменные, аттрибуты , ЖЦ, динамическая компиляция и все, остальное метаданные и другие примочки только расширение уже имеющегося.
А много в C# ты пользуешься перегрузкой операторов???? Они в большей степени для шаблонов.
Статические переменные мало отличаются от глобальных переменных и констант. аттрибуты , ЖЦ, динамическая компиляция это только в Net
AVK>И это ты считаешь мало?

Полязыка переделали. В С++/CLI и то изменений поменьше будет, не говоря уж об МС++.
Да уж. Единный базовый класс, компонентность, рефлексия это совсем немного.

... << RSDN@Home 1.1.0 stable >>

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

S> Дык не дают свободу творчества. В другой лагерь перешел однако. С волками жить по волчьи выть.

А, ну ну.

Почитай интервью с ним, там он очень многое рассказывает.

... << RSDN@Home 1.1.3 stable >>

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

S> И много в Quake нетовских примочек???? Компоненты там разные интерфейсы динамические массивы, IsAssignableFrom, метаклассы итд и 100% unsafe код!!!

И что? При портировании Дельфового кода без правки тоже нетовских примочек не особо.

... << RSDN@Home 1.1.3 stable >>

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

S>>> В Delphi появилась только перегрузка операторов, и статические переменные, аттрибуты , ЖЦ, динамическая компиляция и все, остальное метаданные и другие примочки только расширение уже имеющегося.
S> А много в C# ты пользуешься перегрузкой операторов????

Бывает.

S> Статические переменные мало отличаются от глобальных переменных и констант.

Ага, совсем не отличаются

.

S> аттрибуты , ЖЦ, динамическая компиляция это только в Net

Ну и? Язык сильно модифицирован, а ты тут сказки рассказываешь о том что Дельфи на дотнет похожа.

AVK>>И это ты считаешь мало?

Полязыка переделали. В С++/CLI и то изменений поменьше будет, не говоря уж об МС++.
S> Да уж. Единный базовый класс, компонентность, рефлексия это совсем немного.

Это очень много. Это точно больше чем в МС++. Так что не рассказывай сказок.

... << RSDN@Home 1.1.3 stable >>

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

kuj>>Я вот никогда не был "дельфистом", однако, в .NET без проблем ориентируюсь. Дельфисту все же сложнее будет, т.к. ему не известны такие понятия как, например, пространство имен (C++), построение "цепочек" делегатов (C++, мультиметод), атрибуты (C++, атрибутивный COM в ATL)...
AK>И что с этого. ИМХО, в этом не так сложно разобраться если потребуется.
Несомненно. Но речь-то про относительную сложность.

... << RSDN@Home 1.1.3 stable >>

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

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

S>> И много в Quake нетовских примочек???? Компоненты там разные интерфейсы динамические массивы, IsAssignableFrom, метаклассы итд и 100% unsafe код!!!

AVK>И что? При портировании Дельфового кода без правки тоже нетовских примочек не особо.
Борланд хорошо поработал, приведя все как нужно IsAssignableFrom=class function InheritsFrom(AClass: TClass): Boolean;
метаклассы создаются автоматически, поддержка как AnsiString так нетовских.
Нетовские примочки появляются когда нужно расширить возможности. И вообще можно воспринимать Delphi 8 как следующая версия от Delphi 7.
Delphi 2 отличалась от Delphi 1 намного больше.
А вообщето С подобные языки форева, остальные отстой. Пусть Будет Так!!!!

... << RSDN@Home 1.1.0 stable >>

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

NF>А зачем допускать ошибки?!

NF> Ошибки должны быть устранены в процессе отладки и тестирования.

А. Ну, ну. Люблю смотреть на таких смелых в ночь после установки новой версии заказчикам.

NF> А по стабильности C++ как раз на первом месте.

Смешно.

NF> Хотя, настоящий художник может сделать кистью шедевр, а неуч только загадит холст...

Ага а трепач можеть все... но только на словах.

... << RSDN@Home 1.1.3 beta 2 >>

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

AVK>>И что? При портировании Дельфового кода без правки тоже нетовских примочек не особо.
S> Борланд хорошо поработал,

Мужик, тебе не кажется что ты сам себе противоречишь? То ты утверждаешь что Дельфи похожа на дотнет, теперь утверждаешь что Борланд хорошо поработал. Если Дельфи была похожа на дотнет то зачем Борланду было над ней работать?

Вобщем занимаешься ты ерундой — Дельфи 8 очень существенно была доработана, об этом, кстати, говорит и срок, который понадобился Борланду от начала работ до выпуска продукта. Дельфи и дотнет с джавой различаются концептуально, это просто другой мир, а вот подобных же отличий у него и С++, за исключением разве что шаблонов, нет. Программы на чистом WinAPI похожи как близнецы-братья.

S> Delphi 2 отличалась от Delphi 1 намного больше.

А, ну ну, рассказывай сказки кому нибудь другому. Нет бы еще 3 или 4 помянул, где действительно язык подправили.

S> А вообщето С подобные языки форева, остальные отстой. Пусть Будет Так!!!!

Мне лично С-подобность по барабану.

... << RSDN@Home 1.1.3 stable >>

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

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

S>> Дык не дают свободу творчества. В другой лагерь перешел однако. С волками жить по волчьи выть.

AVK>А, ну ну.

AVK>Почитай интервью с ним, там он очень многое рассказывает.
Смотря какие. Есть много где вспоминаются и Turbo Pascal и Delphi. Буду благодарен за ссылочки (а если на русском просто счастлив). Честно говоря Net по сравнению с Delphi мастодонт с огромными возможностями но больше засчет количества, многие решения не блещут красотой архитектурных решений, в Delphi мне нравится архитектура как TObject,TClass, TComponent, Менеджер Памяти и вся среда базирующейся на данных китах.
Все очень лаконично, красиво и эффективно.
Но Net это будущее, и не тлько M$ будут вкладывать в него силы. Посмотрим за ее развитием.

... << RSDN@Home 1.1.0 stable >>

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

AVK>>Почитай интервью с ним, там он очень многое рассказывает.
S> Смотря какие.

Есть одно большое интервью, состоящее из более чем десятка частей Брюса Эккеля с кем то еще.

S>Буду благодарен за ссылочки

Они неоднократно приводились на разные части. У меня точной ссылки нет.

S>(а если на русском просто счастлив).

Не видел.

S>Честно говоря Net по сравнению с Delphi мастодонт с огромными возможностями но больше засчет количества, многие решения не блещут красотой архитектурных решений, в Delphi мне нравится архитектура как TObject,TClass, TComponent, Менеджер Памяти и вся среда базирующейся на данных китах.

На вкус и цвет. По мне так VCL уже с 4 версии начал превращаться в свалку технологий. То что есть в последних версиях просто убивает — жуткое нагромождение фич, непродуманная иерархия и прочая (собственно это была основная причина, из-за которой после 6 лет использования я от Дельфи отказался). Вобщем VCL нуждается в глубочайшем рефакторинге.

S> Все очень лаконично, красиво и эффективно.

Ага, красиво сделан докинг, не правда ли? Очень красиво дублируется код в DB-aware контролах, да и само их существование удивительно красиво. Офигительно красив примитивнейший биндинг. Безукоризненно логично поведение обычных указателей и указателей на интерфейсы. Вобщем сдается мне что ты просто не использовал Дельфи в серьезных проектах, только баловался с ней, как и с дотнетом.

S> Но Net это будущее, и не тлько M$ будут вкладывать в него силы. Посмотрим за ее развитием.

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

... << RSDN@Home 1.1.3 stable >>

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

AVK>>Практически любой.
S> Хорошо С++ . Манагед и инманагед сильно отличаются.
Есть поддержка компиляции managed и unmanaged C++ кода в одну сборку.
S>Васик.Нет практически совершенно другой язык.Смалталк тоже практически многое потерял.
Почему тоже?
S> В Delphi появилась только перегрузка операторов, и статические переменные, аттрибуты , ЖЦ, динамическая компиляция и все, остальное метаданные и другие примочки только расширение уже имеющегося. Виртуальные статические методы остались, как работа с динамическими массивами (строками) поддержка интерфейсов итд. Компонентная модель практически осталась старая. Тот кто не увлекался указателями практически безболезненно переносят все приложения, что не скажешь о других языках.
Я не понимаю на чем основана Ваша уверенность. У Вас уже был опыт такого переноса?

... << RSDN@Home 1.1.3 stable >>

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

S>>> В Delphi появилась только перегрузка операторов, и статические переменные, аттрибуты , ЖЦ, динамическая компиляция и все, остальное метаданные и другие примочки только расширение уже имеющегося.
S> А много в C# ты пользуешься перегрузкой операторов???? Они в большей степени для шаблонов.
А зачем шаблонам перегрузка операторов?
AVK>>И это ты считаешь мало?

Полязыка переделали. В С++/CLI и то изменений поменьше будет, не говоря уж об МС++.
S> Да уж. Единный базовый класс, компонентность, рефлексия это совсем немного.
Атрибуты, пространства имен... — совсем "немного"... Кстати, MC++ действительно заметно меньше изменений претерпел.

... << RSDN@Home 1.1.3 stable >>

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

AVK>Вобщем занимаешься ты ерундой — Дельфи 8 очень существенно была доработана, об этом, кстати, говорит и срок, который понадобился Борланду от начала работ до выпуска продукта. Дельфи и дотнет с джавой различаются концептуально, это просто другой мир, а вот подобных же отличий у него и С++, за исключением разве что шаблонов, нет. Программы на чистом WinAPI похожи как близнецы-братья.
Отнюдь. Особенно, когда речь заходит о работе со строками.

... << RSDN@Home 1.1.3 stable >>

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

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

AVK>>>И что? При портировании Дельфового кода без правки тоже нетовских примочек не особо.
S>> Борланд хорошо поработал,

AVK>Мужик, тебе не кажется что ты сам себе противоречишь? То ты утверждаешь что Дельфи похожа на дотнет, теперь утверждаешь что Борланд хорошо поработал. Если Дельфи была похожа на дотнет то зачем Борланду было над ней работать?

А как ты хотел, если теже вещи, что в Delphi но по другому называются или вообще нет дельфевых аналогов ?????
У Java с Net тоже мнго общего но ...
AVK>Вобщем занимаешься ты ерундой — Дельфи 8 очень существенно была доработана, об этом, кстати, говорит и срок, который понадобился Борланду от начала работ до выпуска продукта. Дельфи и дотнет с джавой различаются концептуально, это просто другой мир, а вот подобных же отличий у него и С++, за исключением разве что шаблонов, нет. Программы на чистом WinAPI похожи как близнецы-братья.
И чем же концептуально???? Рефлексия заменяется RTTI + метаклассы, атрибуты частично перекрываются метаклассами. Остается GC и динамическая компиляция. Это следующий правильный шаг развития среды выполнения кода, но никак не архитектуры и языка.

S>> Delphi 2 отличалась от Delphi 1 намного больше.

AVK>А, ну ну, рассказывай сказки кому нибудь другому. Нет бы еще 3 или 4 помянул, где действительно язык подправили.
Динамические массивы, Implements, перегрузка методов, reintroduce
А с точки зрения архитектуры не сильно.

... << RSDN@Home 1.1.0 stable >>

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

kuj>Я не понимаю на чем основана Ваша уверенность.

На словах Орлика

... << RSDN@Home 1.1.3 stable >>

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

kuj>Отнюдь. Особенно, когда речь заходит о работе со строками.

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

... << RSDN@Home 1.1.3 stable >>

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

A

S>>Честно говоря Net по сравнению с Delphi мастодонт с огромными возможностями но больше засчет количества, многие решения не блещут красотой архитектурных решений, в Delphi мне нравится архитектура как TObject,TClass, TComponent, Менеджер Памяти и вся среда базирующейся на данных китах.

AVK>На вкус и цвет. По мне так VCL уже с 4 версии начал превращаться в свалку технологий. То что есть в последних версиях просто убивает — жуткое нагромождение фич, непродуманная иерархия и прочая (собственно это была основная причина, из-за которой после 6 лет использования я от Дельфи отказался). Вобщем VCL нуждается в глубочайшем рефакторинге.
VCL умер, и уже ни вчем не нуждается.
S>> Все очень лаконично, красиво и эффективно.

AVK>Ага, красиво сделан докинг, не правда ли? Очень красиво дублируется код в DB-aware контролах, да и само их существование удивительно красиво. Офигительно красив примитивнейший биндинг. Безукоризненно логично поведение обычных указателей и указателей на интерфейсы. Вобщем сдается мне что ты просто не использовал Дельфи в серьезных проектах, только баловался с ней, как и с дотнетом.
А вот обвязка не всегда бывает правильной. Фундамент же был правильный, что мы видим и в Net. А чем тебе не нравятся объекты с подсчетом ссылок, добавь к интерфейсам динамические массивы и строки.
У меня есть 1С и некая организация которая хочет увеличить возможности данной программы, оптимизация торговли, схемы учета и самое главное ускорение работы. Мне особо не нужны окошки. Но кода написанного на Delphi оочень много в том числе и автономного от 1С но с доступом к данным к 1С. И 1С без моих примочек это вообщето разные вещи.

S>> Но Net это будущее, и не тлько M$ будут вкладывать в него силы. Посмотрим за ее развитием.

AVK>Мыши плакали, кололись, но продолжали жрать кактус? Ну какая тебе разница за чем будущее? Ты же балуешся, а дотнет это промышленная платформа. Может тебе лучше действительно переключится на языки вроде Ruby или смолтолка? Практическая польза конечно сомнительна, но так тебе ж она и не нужна.
Ну зачем же не нужна. 1С это не тлько конфигуратор, приходится дополнять ее за счет ВК или Олеавтоматион. И здесь часть делается на Delphi, а часть и на Net, все от ситуации. Да и 1С на Net рано или поздно перейдет. Зачем мне тогда Ruby. А может и под Парусом поработаю.
Все возможно.

... << RSDN@Home 1.1.0 stable >>

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

AVK>>Мужик, тебе не кажется что ты сам себе противоречишь? То ты утверждаешь что Дельфи похожа на дотнет, теперь утверждаешь что Борланд хорошо поработал. Если Дельфи была похожа на дотнет то зачем Борланду было над ней работать?

S> А как ты хотел, если теже вещи, что в Delphi но по другому называются или вообще нет дельфевых аналогов ?????

Ну то есть на самом деле Дельфи весьма серьезно от дотнета и джавы отличается? Ну так чего ж тогда споришь?

S> У Java с Net тоже мнго общего но ...

Что но? Вот там действительно похожа именно идеология. А вот с Дельфей сходство исключительно внешнее, шелуха. Копнешь чуть глубже и понимаешь — два разных мира и сходство зачастую такое же как сходство самолетов разных фирм — законы аэродинамики, они у всех одинаковые.

AVK>>Вобщем занимаешься ты ерундой — Дельфи 8 очень существенно была доработана, об этом, кстати, говорит и срок, который понадобился Борланду от начала работ до выпуска продукта. Дельфи и дотнет с джавой различаются концептуально, это просто другой мир, а вот подобных же отличий у него и С++, за исключением разве что шаблонов, нет. Программы на чистом WinAPI похожи как близнецы-братья.
S> И чем же концептуально????

Управляемый код.

S> Рефлексия заменяется RTTI + метаклассы,

Сказочник

S> атрибуты частично перекрываются метаклассами.

Декларативное программирование императивным? Мда, зашибись аналоги нашел.

S> Остается GC и динамическая компиляция.

Остается еще море различных технологий. Например CAS или side-by-side execution.

S> Это следующий правильный шаг развития среды выполнения кода, но никак не архитектуры и языка.

Нельзя отделять C# от рантайма, по отдельности он не существует.

AVK>>А, ну ну, рассказывай сказки кому нибудь другому. Нет бы еще 3 или 4 помянул, где действительно язык подправили.
S> Динамические массивы, Implements, перегрузка методов, reintroduce

Во второй дельфи? Блин, да ты еще ее наверное и не запускал ни разу. Основное отличие первой и второй дельфи было в целевых платформах — первая компилировала под Win16, вторая под Win32. Там даже для comctl32 оберток не было, ребята очень торопились. Большая часть того о чем ты написал появилась в четвертой версии.

... << RSDN@Home 1.1.3 stable >>

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

kuj>Я не понимаю на чем основана Ваша уверенность. У Вас уже был опыт такого переноса?
http://www.rsdn.ru/forum/Message.aspx?mid=577195&only=1
Это просто пример небольших различий. Delphi далек от Win Api и применение указателей не повсеместно (хотя я их очень любля).
Но совместимость около 90%

... << RSDN@Home 1.1.0 stable >>

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

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

S>>>> В Delphi появилась только перегрузка операторов, и статические переменные, аттрибуты , ЖЦ, динамическая компиляция и все, остальное метаданные и другие примочки только расширение уже имеющегося.
S>> А много в C# ты пользуешься перегрузкой операторов???? Они в большей степени для шаблонов.
kuj>А зачем шаблонам перегрузка операторов?
Вместо компараторов и единый синтаксис при преобразовании шаблонов в нормальный код.
AVK>>>И это ты считаешь мало?

Полязыка переделали. В С++/CLI и то изменений поменьше будет, не говоря уж об МС++.
S>> Да уж. Единный базовый класс, компонентность, рефлексия это совсем немного.
kuj>Атрибуты, пространства имен... — совсем "немного"... Кстати, MC++ действительно заметно меньше изменений претерпел.
Еще раз аттрибуты частично перекрываются RTTI и метаклассами, пространства имен мало отличаются от модульности кстати и в Delphi 8,
осталась таже модульность только с расширением Unit1.Unit2.
Появилась перегрузка операторов. C++ с точки зрения архитектуры классов это вообще разные языки, т.к. класс и структура в С++ одно и тоже,
в отличие от единого базового класса и иерархии классов очень схожих как в Delphi и Яве.
А вообще пусть будет по твоему.

... << RSDN@Home 1.1.0 stable >>

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

AVK>>На вкус и цвет. По мне так VCL уже с 4 версии начал превращаться в свалку технологий. То что есть в последних версиях просто убивает — жуткое нагромождение фич, непродуманная иерархия и прочая (собственно это была основная причина, из-за которой после 6 лет использования я от Дельфи отказался). Вобщем VCL нуждается в глубочайшем рефакторинге.
S> VCL умер, и уже ни вчем не нуждается.

Это он сейчас умер, а тогда был еще вполне себе живой.

AVK>>Ага, красиво сделан докинг, не правда ли? Очень красиво дублируется код в DB-aware контролах, да и само их существование удивительно красиво. Офигительно красив примитивнейший биндинг. Безукоризненно логично поведение обычных указателей и указателей на интерфейсы. Вобщем сдается мне что ты просто не использовал Дельфи в серьезных проектах, только баловался с ней, как и с дотнетом.
S> А вот обвязка не всегда бывает правильной.

А мне плевать, обвязка это или фундамент. Главное одно — кривизна наличествует, причем немалая.

S> А чем тебе не нравятся объекты с подсчетом ссылок,

Нелогичностью и неявностью.

AVK>>Мыши плакали, кололись, но продолжали жрать кактус? Ну какая тебе разница за чем будущее? Ты же балуешся, а дотнет это промышленная платформа. Может тебе лучше действительно переключится на языки вроде Ruby или смолтолка? Практическая польза конечно сомнительна, но так тебе ж она и не нужна.
S> Ну зачем же не нужна. 1С это не тлько конфигуратор, приходится дополнять ее за счет ВК или Олеавтоматион.

Для этого дотнет подходит плохо ввиду того что работа с СОМ идет через маршалер. Точка.

S> И здесь часть делается на Delphi, а часть и на Net, все от ситуации.

А зачем тебе дотнет?

S> Да и 1С на Net рано или поздно перейдет.

Ну жди, жди.

S> Зачем мне тогда Ruby.

А зачем дотнет?

S>А может и под Парусом поработаю.

Под которым?

... << RSDN@Home 1.1.3 stable >>

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

S>> У Java с Net тоже мнго общего но ...

AVK>Что но? Вот там действительно похожа именно идеология. А вот с Дельфей сходство исключительно внешнее, шелуха. Копнешь чуть глубже и понимаешь — два разных мира и сходство зачастую такое же как сходство самолетов разных фирм — законы аэродинамики, они у всех одинаковые.

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

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

TL>

Попрошу не трогать "самолеты разных фирм": законы аэродинамики — они хоть и у всех одинаковые, однако позволяют проектировать весьма разнообразные аэродинамические схемы.

Однако в итоге иногда получается очень похоже

. Тырят?

... << RSDN@Home 1.1.3 stable >>

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

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

AVK>>>Мужик, тебе не кажется что ты сам себе противоречишь? То ты утверждаешь что Дельфи похожа на дотнет, теперь утверждаешь что Борланд хорошо поработал. Если Дельфи была похожа на дотнет то зачем Борланду было над ней работать?

S>> А как ты хотел, если теже вещи, что в Delphi но по другому называются или вообще нет дельфевых аналогов ?????

AVK>Ну то есть на самом деле Дельфи весьма серьезно от дотнета и джавы отличается? Ну так чего ж тогда споришь?
То есть компонентность и сравнительно одинаковая архитектура классов в схожесть не входит????
Техника программирования чуть чуть отличается в Delphi и Net и Java (Free не надо вызывать). А is, as итд осталось тем же.
S>> У Java с Net тоже мнго общего но ...

AVK>Что но? Вот там действительно похожа именно идеология. А вот с Дельфей сходство исключительно внешнее, шелуха. Копнешь чуть глубже и понимаешь — два разных мира и сходство зачастую такое же как сходство самолетов разных фирм — законы аэродинамики, они у всех одинаковые.
Немного другая иерархия классов, отличаются и базовый класс как и в Delphi.

AVK>>>Вобщем занимаешься ты ерундой — Дельфи 8 очень существенно была доработана, об этом, кстати, говорит и срок, который понадобился Борланду от начала работ до выпуска продукта. Дельфи и дотнет с джавой различаются концептуально, это просто другой мир, а вот подобных же отличий у него и С++, за исключением разве что шаблонов, нет. Программы на чистом WinAPI похожи как близнецы-братья.
S>> И чем же концептуально????
Ну если учесь компилятор (кстати некоторые вещи инлайнятся), метаклассы, отладчик (кстати сильно уступающий M$) и прочей лабуды как
введенной в Delphi Net как ECO,StarTeam® ,CaliberRM™, Togethe, BDP итд

Кстати языковые различия

Features C# has that Delphi doesn't
===================================
1) foreach
2) operators using, lock, checked and unchecked
3) block scoped variables
4) case statements with strings
5) assembly internal classes
6) namespaces can span code units
7) implicit array dimensioning: int[] a = new int[1,2,3];
8) ternary operator ( ? : )
9) can use classes from namespaces without importing the whole namespace
10) circular references are possible
11) try..catch..finally
12) assignment operators (+=, ++, -=, etc)
13) multi-file assemblies
14) You don't need to distribute Borland.Delphi.dll

Features Delphi has that C# doesn't
===================================
1) sub-range types
2) enums and sets are first-class types
3) class type support
4) virtual constructors
5) virtual class methods
6) nested procedures
7) non-default index properties
8) can defines constant arrays and records
9) resourcestring s
10) default parameters
11) variants
12) arrays with non-integral subscripts
13) sets with more than 64 elements
14) message handlers
15) unions (variant records)
16) untyped parameters
17) const parameters

AVK>Управляемый код.
Управляемый код касается среды выполнения и мало влияет на архитектуры базового класса и иерархии классов, компонентность
S>> Рефлексия заменяется RTTI + метаклассы,

AVK>

Сказочник
Не совсем. Если еще сюда присобачить TLB то вообще разница сильно стирается.

S>> атрибуты частично перекрываются метаклассами.

AVK>Декларативное программирование императивным? Мда, зашибись аналоги нашел.
Но выполняющие одно и тоже (Attribute.GetCusomAttribute).

S

AVK>>>А, ну ну, рассказывай сказки кому нибудь другому. Нет бы еще 3 или 4 помянул, где действительно язык подправили.
S>> Динамические массивы, Implements, перегрузка методов, reintroduce

AVK>Во второй дельфи?
Я имел ввиду четверку. А 1 и 2 архитектурно.
Все сдаюсь. Займусь лучше делом.

... << RSDN@Home 1.1.0 stable >>

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

S>> И здесь часть делается на Delphi, а часть и на Net, все от ситуации.

AVK>А зачем тебе дотнет?

Ну многих классов в Delphi нет, а самому делать лениво. Интегрировать несложно. В основном все действия выполняются в ВК в 1С передаются только результаты.

S>>А может и под Парусом поработаю.

AVK>Под которым?
Надеюсь новый под Net скоро выйдет если 1С не хочет.

... << RSDN@Home 1.1.0 stable >>

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

Да и M$ скоро Акзапту с Навижн под Net выпустят. Не на одной 1С свет клином сошелся. А тут Я со знанием Net!!!!!

... << RSDN@Home 1.1.0 stable >>

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

S> Да и M$ скоро Акзапту с Навижн под Net выпустят. Не на одной 1С свет клином сошелся. А тут Я со знанием Net!!!!!

А чего же тогда фигней страдаешь, объясняя это тем что тебе интересно?

... << RSDN@Home 1.1.3 stable >>

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

AVK>>Ну то есть на самом деле Дельфи весьма серьезно от дотнета и джавы отличается? Ну так чего ж тогда споришь?
S> То есть компонентность

Компонентность конечно не входит, этой идее сто лет в обед.

S> и сравнительно одинаковая архитектура классов

Архитектура классов это не язык. А то что WinForms на VCL похожи, так это с самого начала сказано было.

S> Техника программирования чуть чуть отличается в Delphi и Net и Java

Рекомендую тебе как можно скорее пересмотреть свои представления о дотнете, ты очень сильно ошибаешься.

S> А is, as итд осталось тем же.

Это все шелуха.

AVK>>Что но? Вот там действительно похожа именно идеология. А вот с Дельфей сходство исключительно внешнее, шелуха. Копнешь чуть глубже и понимаешь — два разных мира и сходство зачастую такое же как сходство самолетов разных фирм — законы аэродинамики, они у всех одинаковые.
S> Немного другая иерархия классов,

Совсем другая, за исключением винформсов.

S>>> И чем же концептуально????
S> Ну если учесь компилятор (кстати некоторые вещи инлайнятся), метаклассы, отладчик (кстати сильно уступающий M$) и прочей лабуды как
S> введенной в Delphi Net как ECO,StarTeam® ,CaliberRM™, Togethe, BDP итд

То что?

S> Кстати языковые различия

S> Features C# has that Delphi doesn't
S>===================================
S>1) foreach
S>2) operators using, lock, checked and unchecked
S>3) block scoped variables
S>4) case statements with strings
S>5) assembly internal classes
S>6) namespaces can span code units
S>7) implicit array dimensioning: int[] a = new int[1,2,3];
S>8) ternary operator ( ? : )
S>9) can use classes from namespaces without importing the whole namespace
S>10) circular references are possible
S>11) try..catch..finally
S>12) assignment operators (+=, ++, -=, etc)
S>13) multi-file assemblies
S>14) You don't need to distribute Borland.Delphi.dll

S>Features Delphi has that C# doesn't
S>===================================
S>1) sub-range types
S>2) enums and sets are first-class types
S>3) class type support
S>4) virtual constructors
S>5) virtual class methods
S>6) nested procedures
S>7) non-default index properties
S>8) can defines constant arrays and records
S>9) resourcestring s
S>10) default parameters
S>11) variants
S>12) arrays with non-integral subscripts
S>13) sets with more than 64 elements
S>14) message handlers
S>15) unions (variant records)
S>16) untyped parameters
S>17) const parameters

И? Как видишь отличий дофига и больше.

AVK>>Управляемый код.
S> Управляемый код касается среды выполнения и мало влияет на архитектуры базового класса и иерархии классов, компонентность

Он влияет кардинально. Без рефлекшена, атрибутов и GC компонентная модель дотнета была бы совсем совсем другой.

S>>> Рефлексия заменяется RTTI + метаклассы,

AVK>>

Сказочник
S> Не совсем. Если еще сюда присобачить TLB то вообще разница сильно стирается.

На языке она стирается. А на практике далеко как до луны.

AVK>>Декларативное программирование императивным? Мда, зашибись аналоги нашел.
S> Но выполняющие одно и тоже (Attribute.GetCusomAttribute).

Не мужик, если ты не понимаешь разницы между императивным и декларативным программированием то это в морг.

AVK>>>>А, ну ну, рассказывай сказки кому нибудь другому. Нет бы еще 3 или 4 помянул, где действительно язык подправили.
S>>> Динамические массивы, Implements, перегрузка методов, reintroduce

AVK>>Во второй дельфи?
S> Я имел ввиду четверку.

Нефиг, все запротоколированно, можешь ознакомится. Ты явно написал версии 1 и 2.

S> А 1 и 2 архитектурно.

Что архитектурно? Отличаются? Нет, не отличаются.

... << RSDN@Home 1.1.3 stable >>

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

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

S>> Да и M$ скоро Акзапту с Навижн под Net выпустят. Не на одной 1С свет клином сошелся. А тут Я со знанием Net!!!!!

AVK>А чего же тогда фигней страдаешь, объясняя это тем что тебе интересно?
Ну иногда то что интересно может давать побочный эффект. Правда к сожалению не в моем случае.

... << RSDN@Home 1.1.0 stable >>

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

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

AVK>>>Ну то есть на самом деле Дельфи весьма серьезно от дотнета и джавы отличается? Ну так чего ж тогда споришь?
S>> То есть компонентность

AVK>Компонентность конечно не входит, этой идее сто лет в обед.
Тоько за счет компонентности у Delphi,Net и превликательна для большинства.

S>> и сравнительно одинаковая архитектура классов

AVK>Архитектура классов это не язык. А то что WinForms на VCL похожи, так это с самого начала сказано было.

S>> Техника программирования чуть чуть отличается в Delphi и Net и Java

AVK>Рекомендую тебе как можно скорее пересмотреть свои представления о дотнете, ты очень сильно ошибаешься.
Постараюсь. Лучше обясни про MarshalByRefObject и потоки в одном домене. Если раньше синхронизация достигалась за счет
PostTreadMessage, PostMessage,QueueUserAPC,CoMarshalInterThreadInterfaceinStream, и обработка TApplication.WndProc(var Message: TMessage);
при установке эвента в сигнальное положение, причем с WM_NULL.
Как добиться выполнение методав потоке котором он был создан через MarshalByRefObject или ObjRef ????

S>> А is, as итд осталось тем же.

S>> Ну если учесь компилятор (кстати некоторые вещи инлайнятся), метаклассы, отладчик (кстати сильно уступающий M$) и прочей лабуды как
S>> введенной в Delphi Net как ECO,StarTeam® ,CaliberRM™, Togethe, BDP итд

AVK>То что?
На это то и была потрачена основная масса времени. Компания то маленькая.

S>> Кстати языковые различия

S>> Features C# has that Delphi doesn't
S>>===================================
S>>1) foreach
S>>2) operators using, lock, checked and unchecked
S>>3) block scoped variables
S>>4) case statements with strings
S>>5) assembly internal classes
S>>6) namespaces can span code units
S>>7) implicit array dimensioning: int[] a = new int[1,2,3];
S>>8) ternary operator ( ? : )
S>>9) can use classes from namespaces without importing the whole namespace
S>>10) circular references are possible
S>>11) try..catch..finally
S>>12) assignment operators (+=, ++, -=, etc)
S>>13) multi-file assemblies
S>>14) You don't need to distribute Borland.Delphi.dll

S>>Features Delphi has that C# doesn't
S>>===================================
S>>1) sub-range types
S>>2) enums and sets are first-class types
S>>3) class type support
S>>4) virtual constructors
S>>5) virtual class methods
S>>6) nested procedures
S>>7) non-default index properties
S>>8) can defines constant arrays and records
S>>9) resourcestring s
S>>10) default parameters
S>>11) variants
S>>12) arrays with non-integral subscripts
S>>13) sets with more than 64 elements
S>>14) message handlers
S>>15) unions (variant records)
S>>16) untyped parameters
S>>17) const parameters

AVK>И? Как видишь отличий дофига и больше.
17 отличий это много у C# и 14 у Delphi ??? И у кого еще больше премуществ????

... << RSDN@Home 1.1.0 stable >>

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

AVK>>Компонентность конечно не входит, этой идее сто лет в обед.
S> Тоько за счет компонентности у Delphi,Net и превликательна для большинства.

Свойством компонентности обладал много кто до Дельфи и много кто после.

AVK>>Рекомендую тебе как можно скорее пересмотреть свои представления о дотнете, ты очень сильно ошибаешься.
S> Постараюсь. Лучше обясни про MarshalByRefObject и потоки в одном домене. Если раньше синхронизация достигалась за счет
S> PostTreadMessage, PostMessage,QueueUserAPC,CoMarshalInterThreadInterfaceinStream, и обработка TApplication.WndProc(var Message: TMessage);
S> при установке эвента в сигнальное положение, причем с WM_NULL.
S> Как добиться выполнение методав потоке котором он был создан через MarshalByRefObject или ObjRef ????

Меня твои переключения темы просто убивают. Заводи топик в соотв. форуме и подробно расписывай что тебе интересно.

... << RSDN@Home 1.1.3 stable >>

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

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

AVK>>>Компонентность конечно не входит, этой идее сто лет в обед.
S>> Тоько за счет компонентности у Delphi,Net и превликательна для большинства.

AVK>Свойством компонентности обладал много кто до Дельфи и много кто после.
Возможно, только Delphi позиционировался как компилируемая альтернатива Васику. И где они эти много ????

AVK>>>Рекомендую тебе как можно скорее пересмотреть свои представления о дотнете, ты очень сильно ошибаешься.
S>> Постараюсь. Лучше обясни про MarshalByRefObject и потоки в одном домене. Если раньше синхронизация достигалась за счет
S>> PostTreadMessage, PostMessage,QueueUserAPC,CoMarshalInterThreadInterfaceinStream, и обработка TApplication.WndProc(var Message: TMessage);
S>> при установке эвента в сигнальное положение, причем с WM_NULL.
S>> Как добиться выполнение методав потоке котором он был создан через MarshalByRefObject или ObjRef ????

AVK>Меня твои переключения темы просто убивают. Заводи топик в соотв. форуме и подробно расписывай что тебе интересно.
А ответить уже в лом. Вообщето это из темы http://www.rsdn.ru/forum/Message.aspx?mid=621601&only=1
Только Тимофей ну никак не хочет отвечать

... << RSDN@Home 1.1.0 stable >>

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

S>>>>> В Delphi появилась только перегрузка операторов, и статические переменные, аттрибуты , ЖЦ, динамическая компиляция и все, остальное метаданные и другие примочки только расширение уже имеющегося.
S>>> А много в C# ты пользуешься перегрузкой операторов???? Они в большей степени для шаблонов.
kuj>>А зачем шаблонам перегрузка операторов?
S> Вместо компараторов и единый синтаксис при преобразовании шаблонов в нормальный код.
Я не понимаю Вас. Поясните, пожалуйста, детальнее.
AVK>>>>И это ты считаешь мало?

Полязыка переделали. В С++/CLI и то изменений поменьше будет, не говоря уж об МС++.
S>>> Да уж. Единный базовый класс, компонентность, рефлексия это совсем немного.
kuj>>Атрибуты, пространства имен... — совсем "немного"... Кстати, MC++ действительно заметно меньше изменений претерпел.
S> Еще раз аттрибуты частично перекрываются RTTI и метаклассами,
Э-э, а как, интересно? Никакой связи не вижу...
S> Появилась перегрузка операторов. C++ с точки зрения архитектуры классов это вообще разные языки,
А как языки можно сравнивать по некой "архитектуре классов"? Поясните.
S>т.к. класс и структура в С++ одно и тоже,
Но их суть (reference type, value type) отличается от их тезок в Delphi Language не менее сильно.
S> в отличие от единого базового класса и иерархии классов очень схожих как в Delphi и Яве.
А что с базовым классом? Вы полагаете, что в C++ нет библиотек с единым (не таким уж и единым в случае Delphi, кстати) базовым классом? Про MFC, например, Вы ничего не слышали?

... << RSDN@Home 1.1.3 stable >>

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

kuj>Но их суть (reference type, value type) отличается от их тезок в Delphi Language не менее сильно.
S>> в отличие от единого базового класса и иерархии классов очень схожих как в Delphi и Яве.
kuj>А что с базовым классом? Вы полагаете, что в C++ нет библиотек с единым (не таким уж и единым в случае Delphi, кстати) базовым классом? Про MFC, например, Вы ничего не слышали?
Разница в том, что если в Delphi я не наследуюсь ни от какого класса, это означает неявное наследование от TObject и все прелести с ним связанные, тогда как в С++ класс, не унаследованный ни от какого другого мало чем от структуры отличается.

Про MFC слышали, но лучше бы не слышали

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

AVK>>>>Ну то есть на самом деле Дельфи весьма серьезно от дотнета и джавы отличается? Ну так чего ж тогда споришь?
S>>> То есть компонентность
AVK>>Компонентность конечно не входит, этой идее сто лет в обед.
S> Тоько за счет компонентности у Delphi,Net и превликательна для большинства.
.NET привлекательна для большинства за счет компонентности у Delphi? Это как?

S>>> и сравнительно одинаковая архитектура классов
AVK>>Архитектура классов это не язык. А то что WinForms на VCL похожи, так это с самого начала сказано было.
Не сильно-то и похожи.

S>>> А is, as итд осталось тем же.
А что еще?

S>>> Кстати языковые различия
S>>> Features C# has that Delphi doesn't
S>>>===================================
S>>>11) try..catch..finally
Вудзрш совсем doesn't it?
S>>>14) You don't need to distribute Borland.Delphi.dll

S>>>Features Delphi has that C# doesn't
S>>>===================================
S>>>1) sub-range types
S>>>2) enums and sets are first-class types
А это как?
S>>>6) nested procedures
Зачем?
S>>>9) resourcestring s
А это что такое?
S>>>11) variants
Зачем?

Есть ведь полноценная метаинформация.
S>>>13) sets with more than 64 elements
Интересно зачем? В каких задачах может понадобиться?
S>>>14) message handlers
Так ведь есть... Или тут подразумевается какая-то особенная языковая конструкция?
S>>>16) untyped parameters
А это как?

AVK>>И? Как видишь отличий дофига и больше.
S> 17 отличий это много у C# и 14 у Delphi ??? И у кого еще больше премуществ????
Преимуществ, судя по всему, больше все-таки у C#.

... << RSDN@Home 1.1.3 stable >>

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

K_O>Разница в том, что если в Delphi я не наследуюсь ни от какого класса, это означает неявное наследование от TObject и все прелести с ним связанные, тогда как в С++ класс, не унаследованный ни от какого другого мало чем от структуры отличается.

В MFC вы тоже не напишете MFC-класс если не отнаследуете от CObject (Отличия тут только в явности и неявности этого наследования). К С++ MFC имеет отношение, только как к языку реализации, а не к общим принципам MFC.

K_O>Про MFC слышали, но лучше бы не слышали

А вот зарабатывать на ней многим удавалось ... особенно часто замечаю, что половина приложений устанавливаемых на моём десктопе за собой тянет mfc40.dll

C Уважением, Andir!

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

[offtop, немного развлечёмся

Не для флейма!]

S>>>> А is, as итд осталось тем же.
kuj>А что еще?

Ну как же перевожу: "А есть, как и т.д. осталось тем же.", то есть налицо абсолютно верная фраза, правда никому не нужная :D

S>>>> Кстати языковые различия
S>>>> Features C# has that Delphi doesn't
S>>>>===================================
S>>>>11) try..catch..finally
kuj>Вудзрш совсем doesn't it?
S>>>>14) You don't need to distribute Borland.Delphi.dll
kuj>

Придёт время и Delphi возьмёт своё и огромный плюс возьмёт своё и с C# приложением придёться распространять Borland.Delphi.dll, хотя даже нет, она будет входить в состав операционной системы, мистер Хейлсберг из лагеря волков об этом позаботиться

S>>>>Features Delphi has that C# doesn't
S>>>>===================================
S>>>>1) sub-range types
S>>>>2) enums and sets are first-class types
kuj>А это как?

Первокласные дельфёвские типы что-ли не узнал?

S>>>>6) nested procedures
kuj>Зачем?

Наследие языка паскаль, анонимные методы очевидно более чем удобны. Однако их нет ведь ни там, ни там

Жаль только что нет
nested constants
nested properties
nested events
nested namespaces — ой а это есть ...

S>>>>9) resourcestring s
kuj>А это что такое?

Ну как же ты можешь не знать, что для того чтобы вытащить строку из ресурсов надо написать специальный класс в C# а вот в дельфи он вот он готовенький (сразу вспоминается любимый дельфистами вопрос: "А где найти компонент для [вставить сюда любое описание]!", правда есть и С++ аналогия: "Помогите ламеру!, Ламерский вопрос! и подобные ламерские заморочки

").

S>>>>11) variants
kuj>Зачем?

Есть ведь полноценная метаинформация.

Э нет батенька, а как же общаться с COM-объектами ... Даёшь вариАнты для выбора, хочу так буду общаться, а захочу смогу и через Дельфи

S>>>>13) sets with more than 64 elements
kuj>Интересно зачем? В каких задачах может понадобиться?

Вы ещё не видели множества с более чем 64 элементами, тогда вам нужна перегрузка операторов и мы уже едем к вам.

S>>>>14) message handlers
kuj>Так ведь есть... Или тут подразумевается какая-то особенная языковая конструкция?

Обработчики сообщений — это нововведение в сегодняшнем программистском мире, Дельфи произвела революцию введя такое понятие в язык

S>>>>16) untyped parameters
kuj>А это как?

Параметры без типов, Типы без параметров ... Лингво вообще такого слова не знает, только знает "untyped language" — язык без контроля типов ...

AVK>>>И? Как видишь отличий дофига и больше.
S>> 17 отличий это много у C# и 14 у Delphi ??? И у кого еще больше премуществ????
kuj>Преимуществ, судя по всему, больше все-таки у C#.

Ну что ты а как же замечательный язык Delphi, который явно превосходит все C-подобные языки из-за своей мощной архитектуры, созданной лет 8 назад ...
А серъёзно, перечислять различия языков — это какой-то нонсенс, то что слова begin — нету в C# не значит, что он не умеет "начинать". Есть языки, коренным образом отличающиеся от C# и ничего, прекрасно адаптируются к платформе .Net и сохраняют все свои основные достоинства, что говорит о довольно продвинутой архитектуре самой платформы.

P.S. Delphi.Net — адаптировалась к .Net намного дольше чем многие языки ... я бы назвал это устареванием положенных в основу концепций

P.S.2 Нисколько не претендую на серъёзность

C Уважением, Andir!

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

S>>> в отличие от единого базового класса и иерархии классов очень схожих как в Delphi и Яве.
kuj>>А что с базовым классом? Вы полагаете, что в C++ нет библиотек с единым (не таким уж и единым в случае Delphi, кстати) базовым классом? Про MFC, например, Вы ничего не слышали?
K_O>Разница в том, что если в Delphi я не наследуюсь ни от какого класса, это означает неявное наследование от TObject и все прелести с ним
K_O> связанные, тогда как в С++ класс, не унаследованный ни от какого другого мало чем от структуры отличается.
Так это ведь наоборот дает определенную гибкость. Не согласны?
K_O>Про MFC слышали, но лучше бы не слышали

Тем не менее он был и на нем писали. При чем писали обычно лучше, чем на Delphi (ну да, вопрос профессионального уровня)...

... << RSDN@Home 1.1.3 stable >>

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

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

S> Да и M$ скоро Акзапту с Навижн под Net выпустят.

Откуда такая информация?

... << RSDN@Home 1.1.3 stable >>

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

A>Жаль только что нет
A>nested constants

Это есть.

... << RSDN@Home 1.1.3 stable >>

G_>>Для кого-то это все ерунда (у него допустим Windows 2003 стоит, где уже есть .NET framework),
G_>>а кого-то из клиентов это оттолкнет. А для компании важны все клиенты, сами понимаете

kuj>В действительности, если уж клиент может позволить себе преобрести ваше ПО, то и скачать 25-30MB для него труда не составит, потому как это копейки.

Это вопрос "порога вхождения", который включает в том числе и время.

G_>>>>1) VCL — достаточно продуманная и гибкая обертка для Windows GUI, которая берет на себя огромную часть рутины и позволяет программировать на высоком уровне абстракций (Button1.Caption := 'Ляля' и т.д.)
А>>>То же самое в WinForms. Как, впрочем, и в VBx(x<7) в связке с ActiveX-компонентами.
G_>>Ну нет. Я согласен, что WinForms как и C# и .NET — хорошая вещь (а как ей не быть таковой, если Microsoft опять .... как бы это выразиться ...
G_>>ну скажем позаимствовала все самые лучше идеи для разработки

kuj>А что Вы в этом видите предосудительного? Разве чьи-то авторские права были нарушены?

Это не в тему, вообще-то.

Но зачем кричать про революционные идеи в .NET, если a) _НИЧЕГО_НОВОГО_ в .NET нету. _Н И Ч Е Г О_.
b) в .NET нет ни одной идеи, которая была _придумана в MS_.
Понимаете? Маркетинговый шум вокруг .NET совершенно не соотвествует содержанию .NET

G_>>Но VB с ActiveX — не предлагать!!!
G_>>Это мертворожденная технология (как VB так и ActiveX) и серьезные вещи на них делать не стоит.
kuj>Тем не менее, на них куда больше действительно серьезных коммерческих проектов. Пример Microstrategy. Разве есть что-то близкое по классу, но написанное на VCL? Я лично не знаю. Так что Вы весьма заблуждаетеся. Delphi (CBuilder) на западе распространены значительно в меньшей степени, чем VB, C++ или Java. Только на просторах постсоветских стран Delphi и CBuilder на столько популярны, что даже в институтах по ним читают целые курсы лекций...

Мы не имеем полной картины о том, где чего используют. Давайте говорить о том, что мы знаем. А мы знаем, что на Delphi
можно сделать все то же, что и на VB + ActiveX. Но! Можно сделать еще кучу всего дополнительного, понимаете?

G_>>>>2) если возможностей VCL не хватает — можно переопределить оконную процедуру и обрабатывать самостоятельно специфические Windows-сообщения или использовать методы со свойством message.
А>>>Но нету PreProcessMessage

G_>>Я же говорю:
kuj>PreProcessMessage позволяет обработать сообщение непосредственно перед dispatch.

Я не понимаю о чем Вы.

G_>>>>компьютере занимает _ПАРУ СЕКУНД_.
А>>>Э-э... Это на проекте, которому уже 4 года? Позволю себе не поверить.
G_>>Только что сделал полный build проекту. Первый раз — 15 секунд. Последующие build (_build_!) — 2-3 секунды (потому как все попало в кеш видимо).
G_>>Напоминаю — build: полное перепостроение всего кода. Размер результирующего приложения: 2253824 байта.
G_>>Общий размер всех pas файлов в проекте — 1.096.671 байт.
kuj>1MB для всех файлов? Так это ма-а-ахонький проектик.

Как Вам удалось растянуть его на 4 года?

Ваш проект?

G_>>>>С++ — не модульный язык. Даже включив всякие оптимизации компилирования, я очень долго __жду__

Это плохо.
А>>>Плохо то, что ты не знаешь, что такое "модульный язык".

Тут дело в другом — компиляторы C++ двупроходные.
G_>>Под модульным в данном случае я подразумеваю схему компиляции и линковки.
kuj>Модульная схема компиляции и линковки? А как это?

C++ компилирует файлы, Delphi компилирует модули.

G_>>>>А Дельфи замечательно переваривает большие проекты (скажем, сейчас у меня в проекте 118 юнитов из них 58 форм) — _никаких_ _тормозов_. Это замечательно.
А>>>По секрету скажу, что 58 форм и 118 юнитов — это *не*большой проект. Ну разве что средний размер одного юнита у тебя — 1MB

G_>>Ну все относительно конечно

Мой предыдущий большой дельфийский проект насчитывал более 100 форм. А каков Ваш наибольший проект?
G_>>Или это из серии "я видел людей которые видели людей которые видели Ленина"?

kuj>Большие проекты насчитывают сотни мегабайт исходного кода (только кода, заметьте).

Ясно. Т.е. вы как раз и есть тот самый, который видел людей, которые видели проекты?

G_>>>>4) Удобная среда, есть все что нужно и работает быстро.
А>>>Удобная среда заканчивается там, где заканчивается мышевозня, то бишь при выходе из дизайнера форм (который, кстати, тоже далеко не идеален — есть и более интересные решения).
G_>>Аргументы?
kuj>Навскидку:
kuj>1. Гайдлайны в дизайнере форм MFC/ATL/WTL.

Это чего такое?

kuj>2. Layout manager`ы в дизайнерах форм Java, .NET

Я бы поспорил насчет того, что жутко удобны. Но в любом случае, что мешает написать самому на Delphi подобную вещь? Delphi легко позволяет
делать подобные вещи.

kuj>3. Размещение невизуальных компонентов вне пределов формы на отдельной специально предназначенной области в дизайнере форм VS.NET

Мне наоборот это кажется неудобным.

kuj>4. Локинг элементов на форме там же.

Это такая защита от дрожащих рук?

kuj>5. Удобный визуальный tab ordering в дизайнере форм MFC/ATL/WTL.
kuj>...

В Delphi — правый клик на форме, выбрать Tab Order...

G_>>2) инлайн... ну да, наверное. тем не менее на Дельфи можно писать полностью ассемблерные процедуры с минимальным overhead, что может и отменит необходимость в инлайн.
kuj>Ассемблерные вставки ухудшают читабельность кода и являются потенциальным глюкодромом, не избавляя тем не менее от overhead`а. В C++ компилятор сам может догадаться проинлайнить тот, либо иной метод.

Это спорное утверждение, я не согласен.

G_>>>>Вообщем, надеюсь главная мысль ясна. Дельфи — замечательная "обертка" для проекта под Windows, он легко "тянет" и маленькие, и большие проекты.
А>>>Маленькие, да, тянет. Большие... — разве что у мазохистов/энтузиастов.
G_>>Аргументы?
kuj>Назову один, но весьма-весьма весомый — в Delphi отсутствуют smart pointers/garbage collector.

Ну не совсем так... Скажем строки (string) — это как раз пример smart pointer с подсчетом ссылок.

G_>>Да я не о том, что кому принадлежит. Я к тому, что .NET вобрала в себя лучшее и безусловно будет доминировать.
kuj>VB, C++, Java безусловно доминировали до создания .NET Да и сейчас, впрочем, Java и C++ доминируют.

Я говорю о длительном перспективе, маркетинг MS всех покроет(

G_>>as и is — не обязательно "костыль"

G_>>Простейший пример — обход контролов на форме с целью прописывания только лейблам какого-то свойства.
G_>>Простой, наглядный код с as и is. (а не static_cast<label> и пр.)
kuj>А зачем в этой задаче static_cast?

В таком случае действительно удобнее было запросить у формы коллекцию этих объектов и пройтись по коллекции оператором foreach. Например, так:

kuj>

kuj>foreach(Label label in MyForm.Controls["Label"]) 
kuj>{
kuj>    label.Text = label.Name;
kuj>    ...
kuj>}
kuj>

Ну хорошо, пусть теперь нужно еще и кнопкам что-то подправить)

G_>>1. создать нормальный мап — совершенно нетривиальная задача! (ну-ка давайте-ка по памяти напишем процедурку удаления узла из красно-черного или AVL дерева, слабо?)

VD>"Нормальные" мапы не пишутся на деревьях. Да и зачем по памяти. В гугле за пять минут можно надыбать алгоритмы. Они очень не сложне. Другое дело что размножать вручную типизированные коллекции без генерации кода не очень разумно. Хотя для одного проекта приемлемо. Не так уж много коллекций обычно в проектах.

Я тоже заметил, что в теории программирования все всегда просто. Взять алгоритм да и внедрить его.
Откуда берутся глючные программы совершенно непонятно...)

G_>>2. стандартизация — великая вещь, а так у каждого будут в проекте свои контейнеры и свои способы работы с ними и т.д., это очень плохо

VD>А кто мешает написать публичную библиотеку? Я вообще не очень понимаю почему для Дельфи библиотек с окошками и феничками хоть завались, а с коллекциями и алгоритмами на пальцах одной руки можно перечесть.

Вот это и плохо. Borland обязана была что предпринять на эту тему.

G_>>То, что STL появилась на свет и успешно существует и очень многими используется доказывает мою правоту.

VD>Ага. А так же ее доказывает. Наличие МФЦ, АТЛ-а, буста, и других библиотек содержащих свои коллекции.

Что конкретно плохо в STL и чем она вас не устраивает?

G_>>Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?)

VD>TBucketList хотя конечно я вряд ли сойду за гуру по Дельфям. Если мне не изменяет память появилась в 6-ке.

Спасибо за инфу, но это все таки хеш. А нужно AVL-дерево или аналог.

G_>> и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi

).

VD>А почему нельзя было отсортировать лист и применять бинарный поиск. Хотя конечно назвать коллекции Дельфей полноценными я бы тоже не осмелился.

Порядок строк важен!

G_>>Далее, серьезный недостаток Delphi Pascal — отсутствие стековых объектов, все объекты — в дин. памяти и соот-но создание объекта и
G_>>его уничтожение приходится делать собственноручно. Т.е. C++:

VD>Вообще-то в дельфи есть тип object и record.

У них нет конструктора/деструктора. Это просто выделить кусок памяти с именованными полями на стеке.

G_>>{
G_>> SOME_STACK stack(some_parameter);
G_>> stack.push(123);
G_>> ...
G_>>}
G_>>// stack уже автоматически уничтожен и его деструктор вызван

VD>Так это наличие автоматического вызова деструктора/финалайзера. В Шарпе этого тоже нет. Но есть IDisposeble и инструкция using.

Да, действительно.

Немного отступая от темы — непонятно зачем вC# делать так неудобно????? Это совместимость с какой-то предыдущей OLE-байдой?
Почему нельзя было для любого класса просто дернуть деструктор вместо наследования IDisposable, переопределения двух методов и пр.
Я не понимаю...

G_>>Шаблоны бы не помешали, но вообще говоря это не must have.

VD>Как минимум более типобезопасно. Так что уж точно не повредит.

G_>>Вообщем, надеюсь главная мысль ясна. Дельфи — замечательная "обертка" для проекта под Windows, он легко "тянет" и маленькие, и большие проекты. А еще лучше он становится, если его доработать своими собственными библиотеками (хоть на C++, хоть на чем еще

. И под него удобно делать и ActiveX-ы и еще много чего другого.

VD>Ну, Дельфи как бы кончился на версии 7. 8-ка уже дотнет-продкт. А дотнет обладает и всеми приемуществами Дельфией и предоставляет кучу других. Те же коллекции там реализованы намного лучше. А после появления дженериков в области коллекций вообще проблем не будет.

Как бы не вышло опять гладко в теории, а на практике...

G_>>PS Один из отцов-основателей Delphi ушел в Microsoft разрабатывать C#, так что нетрудно заметить как отличные идеи в Delphi (скажем as и is) переползли в C#.

VD>Ну, с Явы он точно больше содрал. Из Дельфи больше взято в ВыньФормс. Но это библиотека, а не язык.

Угу.

G_>>PPS К сожалению, Delphi конец.

Мы получим еше одно обновление Delphi 7.1, после чего будет развиваться только Delphi .NET.
G_>>Король умер, да здравствует король.

VD>А от чего же конец то? Дельфи 8 лучше 7-ки хотя бы тем что к ВЦЛ прибавилась огромная ФЦЛ дотнета. Язык стал надежнее. Решены проблемы с тем же Free.

VD>Что так печально то?

Я честно говоря не понял — какой кайф? Хочешь .NET — берешь VS .NET + C# и пишешь. Хочешь нейтив код — берешь Delphi 7 и пишешь.
Смысл появление Delphi .NET от меня ускользнул...Ведь и так можно в C# запускать нейтив код...
Создать очередную всеобъемлющую супер-пупер-унаследованную библиотеку классов?
Не понял я...

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

A>>Жаль только что нет
A>>nested constants

AVK>Это есть.

А что это такое? константы вложенные в константы? Даже представить такое себе не могу

С Уважением, Andir!

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

VD>>Вообще-то в дельфи есть тип object и record.

G_>У них нет конструктора/деструктора. Это просто выделить кусок памяти с именованными полями на стеке.

У object есть.

VD>>Так это наличие автоматического вызова деструктора/финалайзера. В Шарпе этого тоже нет. Но есть IDisposeble и инструкция using.

G_>Да, действительно.

G_>Немного отступая от темы — непонятно зачем вC# делать так неудобно?????

Потому что GC

G_>Это совместимость с какой-то предыдущей OLE-байдой?

Нет

G_>Почему нельзя было для любого класса просто дернуть деструктор

Потому что деструктора нет.

G_> вместо наследования IDisposable,

Реализации, не наследования.

G_> переопределения двух методов

Каких двух методов?

... << RSDN@Home 1.1.3 stable >>

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

G_>Это не в тему, вообще-то.

Но зачем кричать про революционные идеи в .NET

Вот ведь забавная штука — этот аргУмент я слышу регулярно. Где в этом топике кричали про революционные идеи .NET?

G_>, если a) _НИЧЕГО_НОВОГО_ в .NET нету. _Н И Ч Е Г О_.
G_>b) в .NET нет ни одной идеи, которая была _придумана в MS_.

Ну и? Что дальше?

G_>Понимаете? Маркетинговый шум вокруг .NET совершенно не соотвествует содержанию .NET

Ха, маркетинговый шум вобще очень редко соответствует действительности, давно пора это понять. Но мы ведь не маркетинг обсуждаем, не так ли?

kuj>>PreProcessMessage позволяет обработать сообщение непосредственно перед dispatch.

G_>Я не понимаю о чем Вы.

Можно обработать сообщение до того как оно попало в WndProc конкретного окна.

kuj>>Модульная схема компиляции и линковки? А как это?

G_>C++ компилирует файлы, Delphi компилирует модули.

5 баллов за компиляцию модулей, и еще 5 за компиляцию модулей, которые не файлы. В юмор, однозначно.

... << RSDN@Home 1.1.3 stable >>

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

A>>>Жаль только что нет
A>>>nested constants

AVK>>Это есть.

A>А что это такое? константы вложенные в константы? Даже представить такое себе не могу

Константы внутри методов.

... << RSDN@Home 1.1.3 stable >>

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

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

NF>>А зачем допускать ошибки?!

VD>

И правда смешно.

Согласен. Ошибки бывают у всех. Но это не значит, что они обязательно должны присутствовать в программе и их нельзя избежать. Количество ошибок зависит от опыта. (или от количества ошибок, допущенных в прошлом)
NF>> Ошибки должны быть устранены в процессе отладки и тестирования.

VD>А. Ну, ну. Люблю смотреть на таких смелых в ночь после установки новой версии заказчикам.
Что ж. Можно поверить, что Вы действительно видели множество таких людей... Но это уже не является проблемой языка, а топик, если вспомнить, как раз направлен на обсуждение языка, а не человеческих особенностей.
NF>> А по стабильности C++ как раз на первом месте.

VD>Смешно.
Возможно. Но говорить о нестабильности языка, имея в виду невнимательность программиста... Это, на мой взгляд, неправильно.
NF>> Хотя, настоящий художник может сделать кистью шедевр, а неуч только загадит холст...

VD>Ага а трепач можеть все... но только на словах.
Хочу заметить, что я не допускал оскорблений. Это был просто пример. Если он расценен неправильно, то извиняюсь.

... << RSDN@Home 1.1.3 stable >>

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

G_>Спасибо за инфу, но это все таки хеш. А нужно AVL-дерево или аналог.

Ты говорил про мап. Мап самым эффективным образом реализуется на хэш-таблице.

С деревьями у борланда фигово.

G_>Порядок строк важен!

А два листа чем не устраивают?

G_>У них нет конструктора/деструктора. Это просто выделить кусок памяти с именованными полями на стеке.

А что толку в деструкторах в Дельфи? Один фиг вручную вызывать.

G_>Немного отступая от темы — непонятно зачем вC# делать так неудобно????? Это совместимость с какой-то предыдущей OLE-байдой?
G_>Почему нельзя было для любого класса просто дернуть деструктор вместо наследования IDisposable, переопределения двух методов и пр.
G_>Я не понимаю...

Да в общем то сложности никакой нет. Метод переопределят нужно только один.

А почему нет деструктора... Сдается мне это в погоне за чистотой языка. В общем, догмы. Хотя имея трехлетний опыт программирования на Шарпе могу со всей отвественностью заявить, что проблем в этом нет никакий. Финализация нужна крайне редко. И гед она нужна обычно достаточно using-а.

G_>Как бы не вышло опять гладко в теории, а на практике...

Да вот как бы от Дельфи в свое время мы отказались в виду ужасного количества глюков в ВЦЛ-е (еще во времена 4-ой версии), а дотнет вроде как удовлетворяет.

G_>Я честно говоря не понял — какой кайф? Хочешь .NET — берешь VS .NET + C# и пишешь. Хочешь нейтив код — берешь Delphi 7 и пишешь.

Ну, если ты в основном писал на Дельфи, то кайф в том что не нужно переучиваться.

G_>Смысл появление Delphi .NET от меня ускользнул...Ведь и так можно в C# запускать нейтив код...
G_>Создать очередную всеобъемлющую супер-пупер-унаследованную библиотеку классов?
G_>Не понял я...

Думаю, что решение о переводе Дельфи на дотнет было принято не от болды. Скорее всего ребята поняли, что МС серьезно переориентируется на него и решили не упускать шанса.

... << RSDN@Home 1.1.3 beta 2 >>

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

G_>Я тоже заметил, что в теории программирования все всегда просто. Взять алгоритм да и внедрить его.
G_>Откуда берутся глючные программы совершенно непонятно...)

А это из-за велосипидистов.

Не хотят они взять чужой алгорим, а хотят сами по граблям полазить.

G_>Вот это и плохо. Borland обязана была что предпринять на эту тему.

Ну, а без Борланда, что трава не расти? Что только в Борланде грамотные программисты есть?

VD>>Ага. А так же ее доказывает. Наличие МФЦ, АТЛ-а, буста, и других библиотек содержащих свои коллекции.

G_>Что конкретно плохо в STL и чем она вас не устраивает?

Да многим. Есть не продуманные интерфейсы, как у мап-а. Не нравится странные названия многих методов. Не нравится, что что коллекции не имеют полноценного набора методов (все в отдельных функциях). Не нравится примитивность коллекций (могли бы реализовать и блее продвинутые вещи вроде Б+-деревьев и хэш-таблиц, хотя в нестандартных расширениях кое-что есть.)

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

... << RSDN@Home 1.1.3 beta 2 >>

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

NF>И правда смешно.

Согласен. Ошибки бывают у всех. Но это не значит, что они обязательно должны присутствовать в программе и их нельзя избежать. Количество ошибок зависит от опыта. (или от количества ошибок, допущенных в прошлом)

Дело в том, что "опыт" — это не магический кристал вырастающий с годами. Опыт — это стимул подталкивающий к осуществлению действий гарантированно приводящих к меньшему кличеству ошибок. Иными словами это стимул приводящий к применению патернов, применение которых позволяет уменьшить количество ошибок.

Однако есть кода более эффективный спостоб борьбы с ошибками. Если учест опыт других программистов в других языках, то можно изменить язык (илиз создать новый) так чтобы исключить первопричину ошибки.

К сожалению в С++ таких среств маловато, а грабель приводящих к ошибкам достаточно.

VD>>А. Ну, ну. Люблю смотреть на таких смелых в ночь после установки новой версии заказчикам.
NF>Что ж. Можно поверить, что Вы действительно видели множество таких людей... Но это уже не является проблемой языка, а топик, если вспомнить, как раз направлен на обсуждение языка, а не человеческих особенностей.

Гы. Я действительно видел не мало "таких" программистов. И что характерно — это самые обычные (а то и очень даже талантливые) программисты.

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

Самое смешное, что нововведения в этих языках банальны. Они направлены на увеличение типобезопасности и на устранение граблей. Результатом таких изменений является значительное сокращения общего (включающего время на отладку) времени разработки. И это проверенный факт.

NF>Возможно. Но говорить о нестабильности языка, имея в виду невнимательность программиста... Это, на мой взгляд, неправильно.

Говорить нужно о нестабильности програм написанных на языке, а не о нестабильности языка. Но это так о точности терминологии.

Что же касается сути, то как раз не верно, причем в корне, полагаться на внимательность человека. Ему и так хватает проблем. Если можно снять с него часть проблем, то это нужно делать. Так как мозг — это тонкий инструмент причем очень дорогой и использоват его лучше там где он может дать нибольший эффект.

К тому же стабильность — это не только минимум ошибок. Ошибок может быть мало, но их последствия могут быть непоправимы. Например, ошибка в безопасном управляемом коде приводить к исключению причем гарантируется, что при этом не произойдет порчи памяти и т.п. Таким образом банальная обработка ошибок может избавить от необходимости перезапускать приложение и спасет от потери данных.

Изумитльный пример проблем языка — МС Ворд. Он глючит на протяжении всего срока своего существования и программисты МС ничего не могут с этим поделать. А ведь у МС бабок и хороших программистов выше крыши.

VD>>Ага а трепач можеть все... но только на словах.
NF>Хочу заметить, что я не допускал оскорблений. Это был просто пример. Если он расценен неправильно, то извиняюсь.

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

Ладно, не принимай близко к сердцу. Но заявления твои столь же не верны как и безопеляционны. А это не есть гуд. Сомнения — это не стыдно. Без них не может быть найдено верное решение.

... << RSDN@Home 1.1.3 beta 2 >>

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

S> Ага наверное логичнее сравнивать Delphi/Net/Java vc C++. Так как у Net и у Delphi на много больше схожего и дельфисты в Net и Яве как рыбы в воде, чего не скажешь о сишниках.

Остается только один вопрос... Почему те кто освоили Delphi, .Net, Java и C++ очень часто называют себя именно сишниками?

В общем, кончай говорить за других. Я тот самй сишник освоивший все что ты перечислил включая дотнет и чувствую себя в нем как рыба в воде.

... << RSDN@Home 1.1.3 beta 2 >>

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

kuj>построение "цепочек" делегатов (C++, мультиметод),

мультиметоды — это вообще-то немного другое. Это выбор метода на основании рантайм типа. Этого не в С++, не в Шарпе нет. Хотя эмулируется на базе патерна "визитор".

kuj> атрибуты (C++, атрибутивный COM в ATL)...

С++-то тут причем? В Билдере тоже много наворотов, но вот к С++ они отношение имеют очень отдаленное.

... << RSDN@Home 1.1.3 beta 2 >>

2 kuj: Гляжу на твои оценки и не пойму... у тебя раздвоение личности, или просто мышь глючит?

... << RSDN@Home 1.1.3 beta 2 >>

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

S> Смотрим Delphi.Net совместимость с нативной версией 95%. Какой язык еще может позволить такой безболзненный переход ?????
S> Сколько мучаются с С++ ????

Гы-гы. На С++ достаточно врубить ключик /clr и получишь менеджед-приложение. Так что совместимость на 100%.

... << RSDN@Home 1.1.3 beta 2 >>

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

A>>>>nested constants
AVK>>>Это есть.
A>>А что это такое? константы вложенные в константы? Даже представить такое себе не могу

AVK>Константы внутри методов.

Значит у меня с английским беда ...

почему-то был уверен, что nested употребляется для обозначения "вложенный один в другой" ...
Тогда я с nested прокололся

P.S. Спасибо за разъяснения.

С Уважением, Andir!

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

A>Значит у меня с английским беда ...

почему-то был уверен, что nested употребляется для обозначения "вложенный один в другой" ...

Так и есть. Просто один и другой не обязательно одно и то же.

... << RSDN@Home 1.1.3 beta 2 (mobile station) >>

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

VD>К сожалению в С++ таких среств маловато, а грабель приводящих к ошибкам достаточно.
Но, согласитесь, C++ предоставляет огромную гибкость. Он позволяет быстро реализовывать "странные" идеи.

VD>И я видел, да что душой кривить использую постоянно, языки которые позволяют не допускать многие ошибки, или если это не возможно, хотя бы сгладить последствия этих ошибок.
Кстати, о таких языках. Вы имеете в виду, думаю, Delphi. Я сам не так давно пользовался исключительно им. Но он(а может и мои знания по нему) перестал удовлетворять моим запросам. Всё, что в нём удобно, имхо, это дизайн форм... Это моё лично мнение. Но их обычно приходиться делать меньше, чем живого кода.

VD>Самое смешное, что нововведения в этих языках банальны. Они направлены на увеличение типобезопасности и на устранение граблей. Результатом таких изменений является значительное сокращения общего (включающего время на отладку) времени разработки. И это проверенный факт.

А про ошибки типов... Можете не верить, но обычно удаётся заметить их ещё на этапе написания кода. Правда, не всегда, но тем не менее.

VD>Говорить нужно о нестабильности програм написанных на языке, а не о нестабильности языка. Но это так о точности терминологии.
А может быть, о нестабильности программ, написанных программистом?

VD>Что же касается сути, то как раз не верно, причем в корне, полагаться на внимательность человека. Ему и так хватает проблем. Если можно снять с него часть проблем, то это нужно делать. Так как мозг — это тонкий инструмент причем очень дорогой и использоват его лучше там где он может дать нибольший эффект.
Он и даёт наибольший эффект, когда имеет наибольшую свободу.

VD>Изумитльный пример проблем языка — МС Ворд. Он глючит на протяжении всего срока своего существования и программисты МС ничего не могут с этим поделать. А ведь у МС бабок и хороших программистов выше крыши.
Думаю, дело не в языке, а в объёме кода. Там его тоже выше крыши. И такой продукт на Delphi... Это что-то около научной фантастики. Думаю, с этим Вы согласны.

VD>Ладно, не принимай близко к сердцу. Но заявления твои столь же не верны как и безопеляционны. А это не есть гуд. Сомнения — это не стыдно. Без них не может быть найдено верное решение.

... << RSDN@Home 1.1.3 stable >>

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

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

S>>>>>> В Delphi появилась только перегрузка операторов, и статические переменные, аттрибуты , ЖЦ, динамическая компиляция и все, остальное метаданные и другие примочки только расширение уже имеющегося.
S>>>> А много в C# ты пользуешься перегрузкой операторов???? Они в большей степени для шаблонов.
kuj>>>А зачем шаблонам перегрузка операторов?
S>> Вместо компараторов и единый синтаксис при преобразовании шаблонов в нормальный код.
kuj>Я не понимаю Вас. Поясните, пожалуйста, детальнее.
Хотя C#,Delphi.Net и поддерживает перегрузку оператоторов но примняется очень редко, т.к. тянет за собой переопределение многих методов и не столь нужны как при создании шаблонов.
AVK>>>>>И это ты считаешь мало?

Полязыка переделали. В С++/CLI и то изменений поменьше будет, не говоря уж об МС++.
S>>>> Да уж. Единный базовый класс, компонентность, рефлексия это совсем немного.
kuj>>>Атрибуты, пространства имен... — совсем "немного"... Кстати, MC++ действительно заметно меньше изменений претерпел.
S>> Еще раз аттрибуты частично перекрываются RTTI и метаклассами,
kuj>Э-э, а как, интересно? Никакой связи не вижу...
Если брать аттрибуты получаемые через Attribute. GetCustomAttributes. То в Delphi метаклассы хорошо справляются с этой задачей путем кодирования виртуальных статических методов, RTTI тоже многое позволяет, хотя и не идет ни в какое сравнение с рефлексией, но ручками и тогда можно было многое делатью
S>> Появилась перегрузка операторов. C++ с точки зрения архитектуры классов это вообще разные языки,
kuj>А как языки можно сравнивать по некой "архитектуре классов"? Поясните.
Сами по себе языки достаточно одинаковы. Шаблоны тоже не являются языковой фичей. Различие их только на уровне компиляторов.
А вот здесь как раз и проявляются различие в единой иерархии, RTTI управление памятью итд. Введение в Delphi варианта сильно упростило работу не только с валуе типами но и с олеавтоматизацией и программирование стало наиного легче с заранее неизвестными типами.
S>>т.к. класс и структура в С++ одно и тоже,
kuj>Но их суть (reference type, value type) отличается от их тезок в Delphi Language не менее сильно.
Не совсем. В Delphi packed Object сравнима со структурами Net. Объекты вообще близнецы братья. Причем в Delphi.Net через хэлперы была достигнута полная их совместимость.
S>> в отличие от единого базового класса и иерархии классов очень схожих как в Delphi и Яве.
kuj>А что с базовым классом? Вы полагаете, что в C++ нет библиотек с единым (не таким уж и единым в случае Delphi, кстати) базовым классом? Про MFC, например, Вы ничего не слышали?
Дело не разрозненных библиотеках а об общей архитектуре классов. Так при едином базовом классе в этих средах работа выделение памяти, уничтожение, RTTI, работа с типом намного упрощает компиляцию и получение информации о типе в рантайме.
Тенденция развития говорит об этом. Подход С++ отвергнут в угоду гибгости.

... << RSDN@Home 1.1.0 stable >>

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

S>>>>11) variants
kuj>Зачем?

Есть ведь полноценная метаинформация.
Ты с поздним связыванием в C# видно не работал http://www.rsdn.ru/Forum/Message.aspx?mid=621138&only=1
Хотя в у меня варианты с поздним связыванием и не работают но в модуле вариатс такая возможность присутствует.
S>>>>13) sets with more than 64 elements
kuj>Интересно зачем? В каких задачах может понадобиться?
При работе с AnsiChar.

AVK>>>И? Как видишь отличий дофига и больше.
S>> 17 отличий это много у C# и 14 у Delphi ??? И у кого еще больше премуществ????
kuj>Преимуществ, судя по всему, больше все-таки у C#.
На вкус и цвет

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Декларативное программирование императивным? Мда, зашибись аналоги нашел.
S>> Но выполняющие одно и тоже (Attribute.GetCusomAttribute).

AVK>Не мужик, если ты не понимаешь разницы между императивным и декларативным программированием то это в морг.
Большое спасибо. Пошел заказывать место.

S>> А 1 и 2 архитектурно.

AVK>Что архитектурно? Отличаются? Нет, не отличаются.

Хрен с ним, что появились длинные строки, System.Pas (вернее не было исходников этого класса), Перписан Windows.pas, итд
Хватит одного Варианта с его поддержкой компилятором особенно при позднем связывании и их поддержка в БД ,TOlrContainer значительно расширен,
Помню читал книжечку Оле за 21 день. Как я сочувствовал сишникам.
Если для тебя это ничего то ....
1 вообще в глаза не видел, 2 мельком сразу начал с 3 ки. Кстати интерфейсы появились в тройке , в 2 ке взаимодействие было на уровне абстрактных классов и перекрытии методов. До 5 ки шло развитие среды и языка, затем только компонентов. Уход Хэйлсберга всетаки сказался.
Блин из-за тебя столько времени потратил.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Serginio1, Вы писали:

S>> Смотрим Delphi.Net совместимость с нативной версией 95%. Какой язык еще может позволить такой безболзненный переход ?????
S>> Сколько мучаются с С++ ????

VD>Гы-гы. На С++ достаточно врубить ключик /clr и получишь менеджед-приложение. Так что совместимость на 100%.
С MFC,STL и OWL

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Serginio1, Вы писали:

S>>Здравствуйте, AndrewVK, Вы писали:

S>> Да и M$ скоро Акзапту с Навижн под Net выпустят.

L>Откуда такая информация?

http://www.rsdn.ru/Forum/Message.aspx?mid=475852&only=1
http://www.rsdn.ru/Forum/Message.aspx?mid=485167&only=1

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, Serginio1, Вы писали:

L>>Откуда такая информация?

S>http://www.rsdn.ru/Forum/Message.aspx?mid=475852&only=1
S>http://www.rsdn.ru/Forum/Message.aspx?mid=485167&only=1

Да, но это не Аксапта

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Serginio1, Вы писали:

L>>>Откуда такая информация?

S>>http://www.rsdn.ru/Forum/Message.aspx?mid=475852&only=1
S>>http://www.rsdn.ru/Forum/Message.aspx?mid=485167&only=1

L>Да, но это не Аксапта

M$ скупила эти компании и если не хочет потерять клиентов то обязана их и в дальнейшем поддерживать.
Переход на Net преопределен. Либо создадут новый продукт на базе скупленных, либо будут поддерживать но уже на основе технологий Net но с другим ядром. А как новый продукт будет называться не важно. Мы говорим Акзапта на Net подразумеваем нетовского наследника Axapta, Navision, Great Planes и Solomon

... << RSDN@Home 1.1.0 stable >>

Еще
http://idc.mpei.ac.ru/SRV-VMSS/rus/html/edcenter1.htm

В третьих, корпорация Microsoft не ограничивает себя лишь совершенствованием и продвижением на рынок систем MBS Axapta и MBS Navision, хотя в предстоящие три-четыре года они будут основными в объемах продаж. Корпорация решила создать эффективную инструментальную основу для разработки ERP-систем различного масштаба и профиля, названную ею Microsoft Business Framework (MBF). MBF будет интегрирована в среду разработки Visual Studio.NET, одну из наиболее используемых инструментальных сред в мире.

В-четвертых, корпорация Microsoft предполагает дать пользователю полный спектр взаимосвязанных систем базового программного обеспечения таких, как операционная система MS Longhorn, набор бизнес-серверов MS Business Servers, офисная система MS Office System, система автоматизации программирования MS Visual Studio.NET с включенной в нее MBF и, наконец, масштабируемые корпоративные системы MBS Axapta и MBS Navision. Последние будут иметь общую кодовую часть, базирующуюся на MBF и написанную на новом языке C#, который вскоре придется изучать всем, кто собирается разрабатывать сколь-нибудь эффективные программные приложения для локальных корпоративных сетей или глобальной сети Интернет.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, Serginio1, Вы писали:

L>>Да, но это не Аксапта

S> M$ скупила эти компании и если не хочет потерять клиентов то обязана их и в дальнейшем поддерживать.
S> Переход на Net преопределен. Либо создадут новый продукт на базе скупленных, либо будут поддерживать но уже на основе технологий Net но с другим ядром. А как новый продукт будет называться не важно. Мы говорим Акзапта на Net подразумеваем нетовского наследника Axapta, Navision, Great Planes и Solomon

Говорим одно, думаем другое.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Serginio1, Вы писали:

L>>>Да, но это не Аксапта

S>> M$ скупила эти компании и если не хочет потерять клиентов то обязана их и в дальнейшем поддерживать.
S>> Переход на Net преопределен. Либо создадут новый продукт на базе скупленных, либо будут поддерживать но уже на основе технологий Net но с другим ядром. А как новый продукт будет называться не важно. Мы говорим Акзапта на Net подразумеваем нетовского наследника Axapta, Navision, Great Planes и Solomon

L>Говорим одно, думаем другое.

А что на это ответишь http://www.rsdn.ru/forum/Message.aspx?mid=624299&only=1

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, Serginio1, Вы писали:

S> Хрен с ним, что появились длинные строки,

Те же строки что и были, сказался переход на 32 бита.

S> System.Pas (вернее не было исходников этого класса),

О да, серьезное архитектурное изменение.

S> Перписан Windows.pas,

Целиком?

Это опять же вынужденная мера в связи с переходом на Win32. В любом случае к архитектуре это не имеет никакого отношения.

S> Хватит одного Варианта с его поддержкой компилятором особенно при позднем связывании и их поддержка в БД ,TOlrContainer значительно расширен,

Опять ты путаешь версии. Это появилось в Delphi 3. В двойке СОМ был постольку поскольку.

S> Помню читал книжечку Оле за 21 день. Как я сочувствовал сишникам.
S> Если для тебя это ничего то ....
S> 1 вообще в глаза не видел, 2 мельком сразу начал с 3 ки.

Ты про меня? Я начал с первой.

S> Блин из-за тебя столько времени потратил.

Не из-за меня, а из-за себя.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Serginio1, Вы писали:

S>> Хрен с ним, что появились длинные строки,

AVK>Те же строки что и были, сказался переход на 32 бита.

S>> System.Pas (вернее не было исходников этого класса),

AVK>О да, серьезное архитектурное изменение.
А как можно о чем то судить не имея исходного кода.
S>> Перписан Windows.pas,

AVK>Целиком?

Это опять же вынужденная мера в связи с переходом на Win32. В любом случае к архитектуре это не имеет никакого отношения.

S>> Хватит одного Варианта с его поддержкой компилятором особенно при позднем связывании и их поддержка в БД ,TOlrContainer значительно расширен,

AVK>Опять ты путаешь версии. Это появилось в Delphi 3. В двойке СОМ был постольку поскольку.
Блин из-за тебя перечитал еще раз Чарльза Клаверта "Delphi 2" Все там было. Во всяком случае это его слова.
И приведенный код.
S>> Помню читал книжечку Оле за 21 день. Как я сочувствовал сишникам.
S>> Если для тебя это ничего то ....
S>> 1 вообще в глаза не видел, 2 мельком сразу начал с 3 ки.

AVK>Ты про меня? Я начал с первой.
Но читал Чарльза Клаверта "Delphi 2" это была моя первая книга по Delphi. Очень мне понравилась.

S>> Блин из-за тебя столько времени потратил.

AVK>Не из-за меня, а из-за себя.
А у тебя с памятью плохо. Кому верить тебе или Чарльзу Клаверту главу по ОЛЕ он писал кстати с Хэйлсбергом

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, Serginio1, Вы писали:

S>>>>>>> В Delphi появилась только перегрузка операторов, и статические переменные, аттрибуты , ЖЦ, динамическая компиляция и все, остальное метаданные и другие примочки только расширение уже имеющегося.
S>>>>> А много в C# ты пользуешься перегрузкой операторов???? Они в большей степени для шаблонов.
kuj>>>>А зачем шаблонам перегрузка операторов?
S>>> Вместо компараторов и единый синтаксис при преобразовании шаблонов в нормальный код.
kuj>>Я не понимаю Вас. Поясните, пожалуйста, детальнее.
S> Хотя C#,Delphi.Net и поддерживает перегрузку оператоторов но примняется очень редко, т.к. тянет за собой переопределение многих методов и не столь нужны как при создании шаблонов.
Нет. Еще раз. Объясните зачем шаблонам перегрузка операторов?
AVK>>>>>>И это ты считаешь мало?

Полязыка переделали. В С++/CLI и то изменений поменьше будет, не говоря уж об МС++.
S>>>>> Да уж. Единный базовый класс, компонентность, рефлексия это совсем немного.
kuj>>>>Атрибуты, пространства имен... — совсем "немного"... Кстати, MC++ действительно заметно меньше изменений претерпел.
S>>> Еще раз аттрибуты частично перекрываются RTTI и метаклассами,
kuj>>Э-э, а как, интересно? Никакой связи не вижу...
S> Если брать аттрибуты получаемые через Attribute. GetCustomAttributes. То в Delphi метаклассы хорошо справляются с этой задачей путем кодирования виртуальных статических методов, RTTI тоже многое позволяет, хотя и не идет ни в какое сравнение с рефлексией, но ручками и тогда можно было многое делатью
Нет. Это ведь совсем другое. Атрибуты — это декларативный способ описания поведения, а Вы предлагаете использовать императивный да еще и таким способом, что все плюсы данной методики становятся минусами. Понимаете?
S>>> Появилась перегрузка операторов. C++ с точки зрения архитектуры классов это вообще разные языки,
kuj>>А как языки можно сравнивать по некой "архитектуре классов"? Поясните.
S> Сами по себе языки достаточно одинаковы. Шаблоны тоже не являются языковой фичей.
Являются, конечно. Посмотрите спецификацию С++.
S>Различие их только на уровне компиляторов.
Сами себе противоречите...
S> А вот здесь как раз и проявляются различие в единой иерархии,
Так "единая" иерархия это вообще-то фича библиотеки классов, но уж никак не языков. Я же Вам уже напоминал о MFC.
S>>>т.к. класс и структура в С++ одно и тоже,
kuj>>Но их суть (reference type, value type) отличается от их тезок в Delphi Language не менее сильно.
S> Не совсем. В Delphi packed Object сравнима со структурами Net.
Я конечно не считаю себя специалистом по Delphi, но разве behavior у packed object такой же, как у структур в .НЕТ? То бишь тоже value type?
S>Объекты вообще близнецы братья.
Не совсем. Вчасности, поведение деструкторов отличается. Да и, на сколько я знаю, для обычных классов (не COM) Delphi не предоставляет возможности множественного интерфейсного наследования.
S>Причем в Delphi.Net через хэлперы была достигнута полная их совместимость.
Что есть "хэлпер"?
S>>> в отличие от единого базового класса и иерархии классов очень схожих как в Delphi и Яве.
kuj>>А что с базовым классом? Вы полагаете, что в C++ нет библиотек с единым (не таким уж и единым в случае Delphi, кстати) базовым классом? Про MFC, например, Вы ничего не слышали?
S> Дело не разрозненных библиотеках а об общей архитектуре классов.
А что есть "общая архитектура классов"? У MFC, например, архитектура классов вполне себе "общая". Речь, я так понимаю, об архитектуре иерархии классов?
S>Так при едином базовом классе в этих средах работа выделение памяти, уничтожение, RTTI, работа с типом намного упрощает компиляцию и получение информации о типе в рантайме.
Все это есть в MFC. Более того, есть полноценная бинарная сериализация объектов...
S> Тенденция развития говорит об этом. Подход С++ отвергнут в угоду гибгости.
Наоборот — негибкости. Подумайте логически...

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, kuj, Вы писали:

S>> Хотя C#,Delphi.Net и поддерживает перегрузку оператоторов но примняется очень редко, т.к. тянет за собой переопределение многих методов и не столь нужны как при создании шаблонов.
kuj>Нет. Еще раз. Объясните зачем шаблонам перегрузка операторов?

В С++ существует такое понятие "функтор" это объект который ведет себя как функция.

struct some
{
//...
};
struct some_dynamic_cmp
{
    bool operator()(const some& lhs, const some& rhs)
    {
    //Тут сравниваем
    }
};
void main()
{
    std::vector<some> some_vec;
    //Заполняем
    some_dynamic_cmp cmp;
    //Устанавлеваем правила сравнения
    std::sort(some_vec.begin(), some_vec.end(), cmp);
}

kuj>Нет. Это ведь совсем другое. Атрибуты — это декларативный способ описания поведения, а Вы предлагаете использовать императивный да еще и таким способом, что все плюсы данной методики становятся минусами. Понимаете?

Метаклассов нет в Net и этим они сильно обедненны. Частично атрибуты призваны залатывать дыры. Хотя введение атрибутов большой плюс.
S>>>> Появилась перегрузка операторов. C++ с точки зрения архитектуры классов это вообще разные языки,
kuj>>>А как языки можно сравнивать по некой "архитектуре классов"? Поясните.
S>> Сами по себе языки достаточно одинаковы. Шаблоны тоже не являются языковой фичей.
kuj>Являются, конечно. Посмотрите спецификацию С++.
S>>Различие их только на уровне компиляторов.
kuj>Сами себе противоречите...
S>> А вот здесь как раз и проявляются различие в единой иерархии,
kuj>Так "единая" иерархия это вообще-то фича библиотеки классов, но уж никак не языков. Я же Вам уже напоминал о MFC.
Еще раз. В MFC есть единая иерархия но ее нет во всех классах и по количеству не очень хороших откликов о ней можно попытаться найти в чем причина.
S>>>>т.к. класс и структура в С++ одно и тоже,
kuj>>>Но их суть (reference type, value type) отличается от их тезок в Delphi Language не менее сильно.
S>> Не совсем. В Delphi packed Object сравнима со структурами Net.
kuj>Я конечно не считаю себя специалистом по Delphi, но разве behavior у packed object такой же, как у структур в .НЕТ? То бишь тоже value type?
Да единственно, что если packed object будет содержать объекты по выходе из видимости нужно их уничтожать.
S>>Объекты вообще близнецы братья.
kuj>Не совсем. Вчасности, поведение деструкторов отличается. Да и, на сколько я знаю, для обычных классов (не COM) Delphi не предоставляет возможности множественного интерфейсного наследования.
Опятьже Есть класс TInterfacedObject в котором реализован IUnknown

 TInterfacedObject = class(TObject, IInterface)
  protected
    FRefCount: Integer;
    function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
    function _AddRef: Integer; stdcall;
    function _Release: Integer; stdcall;
  public
    procedure AfterConstruction; override;
    procedure BeforeDestruction; override;
    class function NewInstance: TObject; override;
    property RefCount: Integer read FRefCount;
  end;

Наследуясь от которого получаем реализацию IUnknown.

А вот

        function TInterfacedObject.QueryInterface(const IID: TGUID; out Obj): HResult;
begin
  if GetInterface(IID, Obj) then
    Result := 0
  else
    Result := E_NOINTERFACE;
end;

А вот GetInterface(IID, Obj) уже реализован в базовом классе TObject. И InterfaceTable и смещения заполняются на этапе компиляции . Это к тому зачем нуже единый базовый класс и единый базовый метакласс. Если мне нужен объект с поддержкой интерфейсов или с подсчетом ссылок если мне лениво вызывать Free я использую TInterfacedObject иначе TObject Все от ситуации.
S>>Причем в Delphi.Net через хэлперы была достигнута полная их совместимость.
kuj>Что есть "хэлпер"?

Это фича компилятора. Если он не видит метода у объекта он обращается к хэлперу этого класса и если там есть такой метод то вызывает его.
http://www.rsdn.ru/Forum/Message.aspx?mid=548308&pg=1
S>>>> в отличие от единого базового класса и иерархии классов очень схожих как в Delphi и Яве.
kuj>>>А что с базовым классом? Вы полагаете, что в C++ нет библиотек с единым (не таким уж и единым в случае Delphi, кстати) базовым классом? Про MFC, например, Вы ничего не слышали?
S>> Дело не разрозненных библиотеках а об общей архитектуре классов.
kuj>А что есть "общая архитектура классов"? У MFC, например, архитектура классов вполне себе "общая". Речь, я так понимаю, об архитектуре иерархии классов?
S>>Так при едином базовом классе в этих средах работа выделение памяти, уничтожение, RTTI, работа с типом намного упрощает компиляцию и получение информации о типе в рантайме.
kuj>Все это есть в MFC. Более того, есть полноценная бинарная сериализация объектов...
S>> Тенденция развития говорит об этом. Подход С++ отвергнут в угоду гибгости.
kuj>Наоборот — негибкости. Подумайте логически...
Я уже попытался ответить. В любом случае переубеждать не собираюсь.
Но вот по интефейсам дам еще одну ссылочку что бы было понятно зачем нужен единый базовый класс
http://www.rsdn.ru/Forum/Message.aspx?mid=527260&only=1

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, Serginio1, Вы писали:

S>>> Смотрим Delphi.Net совместимость с нативной версией 95%. Какой язык еще может позволить такой безболзненный переход ?????
S>>> Сколько мучаются с С++ ????
VD>>Гы-гы. На С++ достаточно врубить ключик /clr и получишь менеджед-приложение. Так что совместимость на 100%.
S> С MFC,STL
А какая проблема?
S>и OWL
А какое отношение оно имеет к C++.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Serginio1, Вы писали:

S>>> Хотя C#,Delphi.Net и поддерживает перегрузку оператоторов но примняется очень редко, т.к. тянет за собой переопределение многих методов и не столь нужны как при создании шаблонов.
kuj>>Нет. Еще раз. Объясните зачем шаблонам перегрузка операторов?

S>В С++ существует такое понятие "функтор"
патерн
S>это объект который ведет себя как функция.
И где тут шаблоны?
S>

S>struct some
S>{
S>//...
S>};
S>struct some_dynamic_cmp
S>{
S>    bool operator()(const some& lhs, const some& rhs)
S>    {
S>    //Тут сравниваем
S>    }
S>};
S>void main()
S>{
S>    std::vector<some> some_vec;
S>    //Заполняем
S>    some_dynamic_cmp cmp;
S>    //Устанавлеваем правила сравнения
S>    std::sort(some_vec.begin(), some_vec.end(), cmp);
S>}
 


S>

kuj>>Нет. Это ведь совсем другое. Атрибуты — это декларативный способ описания поведения, а Вы предлагаете использовать императивный да еще и таким способом, что все плюсы данной методики становятся минусами. Понимаете?
S> Метаклассов нет в Net и этим они сильно обедненны.
А что такое "метаклассы" в Вашем понимании и в терминологии Делфи?
S>Частично атрибуты призваны залатывать дыры.
О каких, например, дырах идет речь?

S>>>>> Появилась перегрузка операторов. C++ с точки зрения архитектуры классов это вообще разные языки,
kuj>>>>А как языки можно сравнивать по некой "архитектуре классов"? Поясните.
S>>> Сами по себе языки достаточно одинаковы. Шаблоны тоже не являются языковой фичей.
kuj>>Являются, конечно. Посмотрите спецификацию С++.
S>>>Различие их только на уровне компиляторов.
kuj>>Сами себе противоречите...
S>>> А вот здесь как раз и проявляются различие в единой иерархии,
kuj>>Так "единая" иерархия это вообще-то фича библиотеки классов, но уж никак не языков. Я же Вам уже напоминал о MFC.
S> Еще раз. В MFC есть единая иерархия но ее нет во всех классах
Что подразумевается под "всеми классами"?
S>и по количеству не очень хороших откликов о ней можно попытаться найти в чем причина.
Вам доводилось на ней писать или Ваше предположение из категории "слышал звон да не знаю где он"? И разве мы обсуждаем достоинства/недостатки конкретных библиотек?
S>>>Объекты вообще близнецы братья.
kuj>>Не совсем. Вчасности, поведение деструкторов отличается. Да и, на сколько я знаю, для обычных классов (не COM) Delphi не предоставляет возможности множественного интерфейсного наследования.
S> Опятьже Есть класс TInterfacedObject в котором реализован IUnknown
IUnknown — это COM.
S>

S> TInterfacedObject = class(TObject, IInterface)
S>  protected
S>    FRefCount: Integer;
S>    function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
S>    function _AddRef: Integer; stdcall;
S>    function _Release: Integer; stdcall;
S>  public
S>    procedure AfterConstruction; override;
S>    procedure BeforeDestruction; override;
S>    class function NewInstance: TObject; override;
S>    property RefCount: Integer read FRefCount;
S>  end;

S>

S> Наследуясь от которого получаем реализацию IUnknown.
Это все конечно чудесно, но речь-то о другом...

S> А вот GetInterface(IID, Obj) уже реализован в базовом классе TObject. И InterfaceTable и смещения заполняются на этапе компиляции . Это к тому зачем нуже единый базовый класс и единый базовый метакласс. Если мне нужен объект с поддержкой интерфейсов или с подсчетом ссылок если мне лениво вызывать Free я использую TInterfacedObject иначе TObject Все от ситуации.
Это от лукавого — порождает overhead.
S>>>Причем в Delphi.Net через хэлперы была достигнута полная их совместимость.
kuj>>Что есть "хэлпер"?
S> Это фича компилятора. Если он не видит метода у объекта он обращается к хэлперу этого класса и если там есть такой метод то вызывает его.
S> http://www.rsdn.ru/Forum/Message.aspx?mid=548308&pg=1
Больше похоже на костыль.
S>>>Так при едином базовом классе в этих средах работа выделение памяти, уничтожение, RTTI, работа с типом намного упрощает компиляцию и получение информации о типе в рантайме.
kuj>>Все это есть в MFC. Более того, есть полноценная бинарная сериализация объектов...
S>>> Тенденция развития говорит об этом. Подход С++ отвергнут в угоду гибгости.
kuj>>Наоборот — негибкости. Подумайте логически...
S> Я уже попытался ответить. В любом случае переубеждать не собираюсь.
Давайте определимся с терминологией.
1. "Гибкость" характеризуется количеством вариантов решения. Согласны?
2. В С++ мы не привязаны к конкретной библиотеке — хотим используем MFC и пишем для Windows, хотим используем Linux Qt и пишем под X Window. Хотим — вообще не используем классы. Пишем процедурными методами.
В .NET и Delphi мы автоматически привязываемся к System.Object и Object, соответственно.

Так где же гибкость выше?

S> Но вот по интефейсам дам еще одну ссылочку что бы было понятно зачем нужен единый базовый класс
S> http://www.rsdn.ru/Forum/Message.aspx?mid=527260&only=1
Единый базовый класс может быть нужен, а может быть и не нужен. Все зависит от решаемых задач и, собственно, среды, в рамках которых, реализовывается задача.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, kuj, Вы писали:

kuj>>>Нет. Это ведь совсем другое. Атрибуты — это декларативный способ описания поведения, а Вы предлагаете использовать императивный да еще и таким способом, что все плюсы данной методики становятся минусами. Понимаете?
S>> Метаклассов нет в Net и этим они сильно обедненны.
kuj>А что такое "метаклассы" в Вашем понимании и в терминологии Делфи?
S>>Частично атрибуты призваны залатывать дыры.
kuj>О каких, например, дырах идет речь?

Еще раз в Net нет статических виртуальных методов, частично они перекрываются атрибутами но очень дорогой ценой, т.к. каждый раз нужно десериализовывать объект либо его кэшировать.

S>> Еще раз. В MFC есть единая иерархия но ее нет во всех классах
kuj>Что подразумевается под "всеми классами"?
А что можно еще полразумевать??? Единый базовый класс.
S>>и по количеству не очень хороших откликов о ней можно попытаться найти в чем причина.
kuj>Вам доводилось на ней писать или Ваше предположение из категории "слышал звон да не знаю где он"? И разве мы обсуждаем достоинства/недостатки конкретных библиотек?

S>>>>Объекты вообще близнецы братья.
kuj>>>Не совсем. Вчасности, поведение деструкторов отличается. Да и, на сколько я знаю, для обычных классов (не COM) Delphi не предоставляет возможности множественного интерфейсного наследования.
S>> Опятьже Есть класс TInterfacedObject в котором реализован IUnknown
kuj>IUnknown — это COM.
Да уж. COM намного больше чем определие IUnknown. Как видишь IInterface имеет такуюже сигнатуру но различные названия.
А TInterfacedObject это обычный класс.
S>>

S>> TInterfacedObject = class(TObject, IInterface)
S>>  protected
S>>    FRefCount: Integer;
S>>    function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
S>>    function _AddRef: Integer; stdcall;
S>>    function _Release: Integer; stdcall;
S>>  public
S>>    procedure AfterConstruction; override;
S>>    procedure BeforeDestruction; override;
S>>    class function NewInstance: TObject; override;
S>>    property RefCount: Integer read FRefCount;
S>>  end;

S>>

S>> Наследуясь от которого получаем реализацию IUnknown.
kuj>Это все конечно чудесно, но речь-то о другом...

S>> А вот GetInterface(IID, Obj) уже реализован в базовом классе TObject. И InterfaceTable и смещения заполняются на этапе компиляции . Это к тому зачем нуже единый базовый класс и единый базовый метакласс. Если мне нужен объект с поддержкой интерфейсов или с подсчетом ссылок если мне лениво вызывать Free я использую TInterfacedObject иначе TObject Все от ситуации.
kuj>Это от лукавого — порождает overhead.
И где он??? И где лукавство??? Это пример продуманной архитектуры классов. Экономия огромного количества времени на рутину.
S>>>>Причем в Delphi.Net через хэлперы была достигнута полная их совместимость.
kuj>>>Что есть "хэлпер"?
S>> Это фича компилятора. Если он не видит метода у объекта он обращается к хэлперу этого класса и если там есть такой метод то вызывает его.
S>> http://www.rsdn.ru/Forum/Message.aspx?mid=548308&pg=1
kuj>Больше похоже на костыль.
Как скажешь. Только за счет костылей полностью совместимый код с Net. И в чем костыли??? Это фича компилятора очень удобно когда нужно расширить код не прибегая к наследованию в том числе и saled классов.
S>>>>Так при едином базовом классе в этих средах работа выделение памяти, уничтожение, RTTI, работа с типом намного упрощает компиляцию и получение информации о типе в рантайме.
kuj>>>Все это есть в MFC. Более того, есть полноценная бинарная сериализация объектов...
S>>>> Тенденция развития говорит об этом. Подход С++ отвергнут в угоду гибгости.
kuj>>>Наоборот — негибкости. Подумайте логически...
S>> Я уже попытался ответить. В любом случае переубеждать не собираюсь.
kuj>Давайте определимся с терминологией.
kuj>1. "Гибкость" характеризуется количеством вариантов решения. Согласны?
kuj>2. В С++ мы не привязаны к конкретной библиотеке — хотим используем MFC и пишем для Windows, хотим используем Linux Qt и пишем под X Window. Хотим — вообще не используем классы. Пишем процедурными методами.
kuj>В .NET и Delphi мы автоматически привязываемся к System.Object и Object, соответственно.
Гибкость в создании сложной иерархии классов прежде всего, RTTI и уменьшение количества кода. Kylix тоже используется CLX.
Кроме того а кто мешает использовать статические методы????
Единая иерархия только требует поля со ссылкой на VMT (в Net еще на блок синхронизации который еще используется и при Objet.GetHashCode), плюс выделение памяти не в стеке (хотя и там можно, но грабли при передачи ссылки можно получить). И тебя эти затраты так смущают.
А ручная гибкость уже никому не нужна в сложных системах.
kuj>Так где же гибкость выше?

S>> Но вот по интефейсам дам еще одну ссылочку что бы было понятно зачем нужен единый базовый класс
S>> http://www.rsdn.ru/Forum/Message.aspx?mid=527260&only=1
kuj>Единый базовый класс может быть нужен, а может быть и не нужен. Все зависит от решаемых задач и, собственно, среды, в рамках которых, реализовывается задача.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, VladD2, Вы писали:

kuj>>построение "цепочек" делегатов (C++, мультиметод),
VD>мультиметоды — это вообще-то немного другое. Это выбор метода на основании рантайм типа. Этого не в С++, не в Шарпе нет. Хотя эмулируется на базе патерна "визитор".
Chain of Responsibility

kuj>> атрибуты (C++, атрибутивный COM в ATL)...

VD>С++-то тут причем? В Билдере тоже много наворотов, но вот к С++ они отношение имеют очень отдаленное.
При том, что ATL в мире C++ куда как популярнее CBuilder`а. Речь о легкости осуществления перехода.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Serginio1, Вы писали:

kuj>>>>Нет. Это ведь совсем другое. Атрибуты — это декларативный способ описания поведения, а Вы предлагаете использовать императивный да еще и таким способом, что все плюсы данной методики становятся минусами. Понимаете?
S>>> Метаклассов нет в Net и этим они сильно обедненны.
kuj>>А что такое "метаклассы" в Вашем понимании и в терминологии Делфи?
S>>>Частично атрибуты призваны залатывать дыры.
kuj>>О каких, например, дырах идет речь?
S> Еще раз в Net нет статических виртуальных методов,
А зачем нужны статические виртуальные методы?

S>частично они перекрываются атрибутами но очень дорогой ценой,
Каким же образом?
S>т.к. каждый раз нужно десериализовывать объект либо его кэшировать.
Зачем?

S>>> А вот GetInterface(IID, Obj) уже реализован в базовом классе TObject. И InterfaceTable и смещения заполняются на этапе компиляции . Это к тому зачем нуже единый базовый класс и единый базовый метакласс. Если мне нужен объект с поддержкой интерфейсов или с подсчетом ссылок если мне лениво вызывать Free я использую TInterfacedObject иначе TObject Все от ситуации.
kuj>>Это от лукавого — порождает overhead.
S> И где он??? И где лукавство??? Это пример продуманной архитектуры классов. Экономия огромного количества времени на рутину.
overhead в реализация IUnknown для не-COM классов. Подумайте сами — зачем в не co-классе реализация AddRef, Release и QueryInterface...
S>>>>>Причем в Delphi.Net через хэлперы была достигнута полная их совместимость.
kuj>>>>Что есть "хэлпер"?
S>>> Это фича компилятора. Если он не видит метода у объекта он обращается к хэлперу этого класса и если там есть такой метод то вызывает его.
S>>> http://www.rsdn.ru/Forum/Message.aspx?mid=548308&pg=1
kuj>>Больше похоже на костыль.
S> Как скажешь. Только за счет костылей полностью совместимый код с Net. И в чем костыли??? Это фича компилятора очень удобно когда нужно расширить код не прибегая к наследованию в том числе и saled классов.
А что, код можно расширять только наследованием? Агрегацию уже отменили?.. Или для ER-логики придумали нечто более эффективное?
S>>>>>Так при едином базовом классе в этих средах работа выделение памяти, уничтожение, RTTI, работа с типом намного упрощает компиляцию и получение информации о типе в рантайме.
kuj>>>>Все это есть в MFC. Более того, есть полноценная бинарная сериализация объектов...
S>>>>> Тенденция развития говорит об этом. Подход С++ отвергнут в угоду гибгости.
kuj>>>>Наоборот — негибкости. Подумайте логически...
S>>> Я уже попытался ответить. В любом случае переубеждать не собираюсь.
kuj>>Давайте определимся с терминологией.
kuj>>1. "Гибкость" характеризуется количеством вариантов решения. Согласны?
kuj>>2. В С++ мы не привязаны к конкретной библиотеке — хотим используем MFC и пишем для Windows, хотим используем Linux Qt и пишем под X Window. Хотим — вообще не используем классы. Пишем процедурными методами.
kuj>>В .NET и Delphi мы автоматически привязываемся к System.Object и Object, соответственно.
S> Гибкость в создании сложной иерархии классов прежде всего,
Так с созданием иерархии классов в C++ нет особых проблем. Да и с гибкостью, кстати, тоже, потому что: а) множественное наследование,
б) шаблоны, в) пространства имен, г) перегрузка операторов.
S>RTTI и уменьшение количества кода.
RTTI, кстати, подразумевает увеличение количества кода там, где можно обойтись строгой типизацией, на основе шаблонной специализации.
S>Kylix тоже используется CLX.
Ах, CLX...

S> Кроме того а кто мешает использовать статические методы????
Религия.

S> Единая иерархия только требует поля со ссылкой на VMT (в Net еще на блок синхронизации который еще используется и при Objet.GetHashCode), плюс выделение памяти не в стеке (хотя и там можно, но грабли при передачи ссылки можно получить). И тебя эти затраты так смущают.
Смущают. Честно. Есть класс задач, где они излишни, то бишь порождают пресловутый overhead.
S> А ручная гибкость уже никому не нужна в сложных системах.
Весьма спорно.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, NoFate, Вы писали:

VD>>К сожалению в С++ таких среств маловато, а грабель приводящих к ошибкам достаточно.
NF>Но, согласитесь, C++ предоставляет огромную гибкость. Он позволяет быстро реализовывать "странные" идеи.

Странные идеи лучше вообще не реализовывать. Что же касается быстро, то это не так. С++ как раз обычно тормозит процесс разработки. Рано или поздно складывается ситуация когда из-за объемов или сложности проект начинает рассыпаться под собственным весом.

Конечно многое зависить от класса программистов, но если квалифицированный программист получает в руки более удобное и безопасное средсво, то скорость разработки значительно увеличивается. Для не опытного же программистоа это вообще единствнно разумное решение.

NF>Кстати, о таких языках. Вы имеете в виду, думаю, Delphi.

Не. К сожалению дельфи мало чем отличается от С++ в аспекте безопасности.

NF> Я сам не так давно пользовался исключительно им. Но он(а может и мои знания по нему) перестал удовлетворять моим запросам. Всё, что в нём удобно, имхо, это дизайн форм... Это моё лично мнение. Но их обычно приходиться делать меньше, чем живого кода.

Это не в корне не верный взгляд на программирование. Попробуй ответить на вопрос почему Дельфи позволяет упростить разработку форм? И ты увидиль, что Дельфи — это компонентная среда, и именно это позволяет сделать стольк простой дизайнер форм. Применяя приимущества компонентной разработки ты можешь значитель упростить многие аспекты разработки.

В общем, Дельфи имеет некоторый набор приемуществ которые отсутсвтуют в классическом С++. С++ тоже имет набор приемуществ. Правда их не так уж и много. Я бы виделил только два — обобщенное программирование и более удобная работа с указателями. Остальное уже не так существенно.

NF>А про ошибки типов... Можете не верить, но обычно удаётся заметить их ещё на этапе написания кода. Правда, не всегда, но тем не менее.

Могу. И видимо по тому, что имею 10-и летний опыт разработки на С++, а так же опыт руководством С++-программистами.

NF>А может быть, о нестабильности программ, написанных программистом?

Программист само собой вносит ошибки. Его класс может снизить их количество или увеличить. Но избавиться от них он не в состоянии.

При этом банальная реализация в языке типобезопастности снижает риск ошибки.

Поменять природу человека очень сложно. Дать же ему более качественные средства разработки относительно просто. Так зечем же упускать реальный шанс поднять качество производимого им ПО?

NF>Он и даёт наибольший эффект, когда имеет наибольшую свободу.

Свобода о которой говришь ты — это лишь илюзия.

Выражать свои мысли можно и на других языках. И за частую это может быть намного изящьнее. Так что это разговоры в пользу бедных.

NF>Думаю, дело не в языке, а в объёме кода. Там его тоже выше крыши. И такой продукт на Delphi... Это что-то около научной фантастики. Думаю, с этим Вы согласны.

Уморил. Да все проблемы программирования в объеме кода. Написать без ошибок "Привет, мир!" можно на любом языке.

Сказки про то что подобный продукт нельзя написать на дельфи или чем-то еще вообще не достойны обсуждения.

Будующие продукты МС будут все больше и больше переписываться/перекомпилироваться на управлямых языках/компиляторах. И делаться это будет именно из-за того, что они могут обеспечить большую надежность и безопасность.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, Serginio1, Вы писали:

VD>>Гы-гы. На С++ достаточно врубить ключик /clr и получишь менеджед-приложение. Так что совместимость на 100%.
S> С MFC,STL и OWL

ЗЫ

Может не стоит обсуждать вопросы в которых не имешь полного понимания?

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, kuj, Вы писали:

kuj>При том, что ATL в мире C++ куда как популярнее CBuilder`а. Речь о легкости осуществления перехода.

Видимо я не очень доходчиво выразился.

ATL никакого отношения к С++ не имеет. Да и нет в нем никаких атрибутов. Атрибуты есть в КОМ и сепециальной надстройке VS.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, Serginio1, Вы писали:

S>В-четвертых, корпорация Microsoft предполагает дать пользователю полный спектр взаимосвязанных систем базового программного обеспечения таких, как операционная система MS Longhorn, набор бизнес-серверов MS Business Servers, офисная система MS Office System, система автоматизации программирования MS Visual Studio.NET с включенной в нее MBF и, наконец, масштабируемые корпоративные системы MBS Axapta и MBS Navision. Последние будут иметь общую кодовую часть, базирующуюся на MBF и написанную на новом языке C#, который вскоре придется изучать всем, кто собирается разрабатывать сколь-нибудь эффективные программные приложения для локальных корпоративных сетей или глобальной сети Интернет.

А там есть ссылка на микрософт? если нет, то это журналистская отсебятина.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Serginio1, Вы писали:

S>>В-четвертых, корпорация Microsoft предполагает дать пользователю полный спектр взаимосвязанных систем базового программного обеспечения таких, как операционная система MS Longhorn, набор бизнес-серверов MS Business Servers, офисная система MS Office System, система автоматизации программирования MS Visual Studio.NET с включенной в нее MBF и, наконец, масштабируемые корпоративные системы MBS Axapta и MBS Navision. Последние будут иметь общую кодовую часть, базирующуюся на MBF и написанную на новом языке C#, который вскоре придется изучать всем, кто собирается разрабатывать сколь-нибудь эффективные программные приложения для локальных корпоративных сетей или глобальной сети Интернет.

L>А там есть ссылка на микрософт? если нет, то это журналистская отсебятина.

Про отсебятину не надо, видел подобную инфу в заслуживающих доверия журналах, да и на самом микрософте вроде информация такая проходила...

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Lloyd, Вы писали:

L>>А там есть ссылка на микрософт? если нет, то это журналистская отсебятина.

К>Про отсебятину не надо, видел подобную инфу в заслуживающих доверия журналах, да и на самом микрософте вроде информация такая проходила...

Линк дашь?

Просто я пытаюсь отслеживать информацию по Аксапте, и ничего о том, что ее будут портировать (именно портировать Аксапту, а не писать новую систему) на Нет, не слышал. Возможно я что-то упустил.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Курилка, Вы писали:

К>>Здравствуйте, Lloyd, Вы писали:

L>>>А там есть ссылка на микрософт? если нет, то это журналистская отсебятина.

К>>Про отсебятину не надо, видел подобную инфу в заслуживающих доверия журналах, да и на самом микрософте вроде информация такая проходила...

L>Линк дашь?

Если бы был — дал бы

L>Просто я пытаюсь отслеживать информацию по Аксапте, и ничего о том, что ее будут портировать (именно портировать Аксапту, а не писать новую систему) на Нет, не слышал. Возможно я что-то упустил.

Посмотри лучше на форумах по аксапте, там гораздо вероятнее найти что-либо более информативное, если найдёшь — интересно было бы услышать

Здравствуйте, Курилка, Вы писали:

L>>Линк дашь?

К>Если бы был — дал бы

Значит отсебятина.

L>>Просто я пытаюсь отслеживать информацию по Аксапте, и ничего о том, что ее будут портировать (именно портировать Аксапту, а не писать новую систему) на Нет, не слышал. Возможно я что-то упустил.

К>Посмотри лучше на форумах по аксапте, там гораздо вероятнее найти что-либо более информативное, если найдёшь — интересно было бы услышать

Смотрю регулярно.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, VladD2, Вы писали:

VD>Странные идеи лучше вообще не реализовывать. Что же касается быстро, то это не так. С++ как раз обычно тормозит процесс разработки. Рано или поздно складывается ситуация когда из-за объемов или сложности проект начинает рассыпаться под собственным весом.
Странные идею нужно реализовывать. Мне кажется, что именно они изменяют окружающую действительность. Спорить со вторым утверждением не буду. Я не встречал процессов рассыпания такого рода проектов. Возможно, потому, что всё, в чём участвовал не имело такого большого объёма или сложности.

VD>Конечно многое зависить от класса программистов, но если квалифицированный программист получает в руки более удобное и безопасное средсво, то скорость разработки значительно увеличивается. Для не опытного же программистоа это вообще единствнно разумное решение.
Согласен. Но что вы считаете более удобным, чем C++ средством? Я могу привести только C#.

VD>В общем, Дельфи имеет некоторый набор приемуществ которые отсутсвтуют в классическом С++. С++ тоже имет набор приемуществ. Правда их не так уж и много. Я бы виделил только два — обобщенное программирование и более удобная работа с указателями. Остальное уже не так существенно.
Ну-у-у... Мелочи, а приятно. Да и преимущества C++, имхо, именно в не слишком жёстком контроле...

VD>Могу. И видимо по тому, что имею 10-и летний опыт разработки на С++, а так же опыт руководством С++-программистами.

Ух ты... Таким опытом похвастать не могу. 5 лет в программировании, из них 2 года на С++... Так что поверим...

VD>Свобода о которой говришь ты — это лишь илюзия.
А свобода — всегда иллюзия.

VD>Сказки про то что подобный продукт нельзя написать на дельфи или чем-то еще вообще не достойны обсуждения.
Приведите, пожалуйста, примеры подобных продуктов, написанных на Delphi.

VD>Будующие продукты МС будут все больше и больше переписываться/перекомпилироваться на управлямых языках/компиляторах. И делаться это будет именно из-за того, что они могут обеспечить большую надежность и безопасность.
Мдя... Очень может быть. Оно и естественно. Прогресс не стоит на месте.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Serginio1, Вы писали:

VD>>>Гы-гы. На С++ достаточно врубить ключик /clr и получишь менеджед-приложение. Так что совместимость на 100%.
S>> С MFC,STL и OWL

VD>

VD>ЗЫ

VD>Может не стоит обсуждать вопросы в которых не имешь полного понимания?
Читать внимательно надо. Я подтвердил. Но как быть с унсейвом. Ведь C++ практически весь на указателях. Или там повсеместно GC.Alloc и интероп????

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, Serginio1, Вы писали:

kuj>>>>>Нет. Это ведь совсем другое. Атрибуты — это декларативный способ описания поведения, а Вы предлагаете использовать императивный да еще и таким способом, что все плюсы данной методики становятся минусами. Понимаете?
S>>>> Метаклассов нет в Net и этим они сильно обедненны.
kuj>>>А что такое "метаклассы" в Вашем понимании и в терминологии Делфи?
S>>>>Частично атрибуты призваны залатывать дыры.
kuj>>>О каких, например, дырах идет речь?
S>> Еще раз в Net нет статических виртуальных методов,
kuj>А зачем нужны статические виртуальные методы?

На них вся Delphi построена и компонентная модель (информация о типе, виртуальные конструкторы при создании объектов из метаклассов, пользовательская информация о типе ее расширение, в том числе и десериализация итд).
S>>частично они перекрываются атрибутами но очень дорогой ценой,
kuj>Каким же образом?
Attribute.GetCustomAttribute.
S>>т.к. каждый раз нужно десериализовывать объект либо его кэшировать.
kuj>Зачем?

Потому что разберись на досуге с Attribute.GetCustomAttribute.
S>>>> А вот GetInterface(IID, Obj) уже реализован в базовом классе TObject. И InterfaceTable и смещения заполняются на этапе компиляции . Это к тому зачем нуже единый базовый класс и единый базовый метакласс. Если мне нужен объект с поддержкой интерфейсов или с подсчетом ссылок если мне лениво вызывать Free я использую TInterfacedObject иначе TObject Все от ситуации.
kuj>>>Это от лукавого — порождает overhead.
S>> И где он??? И где лукавство??? Это пример продуманной архитектуры классов. Экономия огромного количества времени на рутину.
kuj>overhead в реализация IUnknown для не-COM классов. Подумайте сами — зачем в не co-классе реализация AddRef, Release и QueryInterface...
Есть строки, динамические массивы поддерживающие подсчет ссылок (AddRef, Release) но они не ком классы. Вместо QueryInterface в Delphi поддерживается конструкция as. То есть программирование с интерфейсами по технике такое же как и в Net. А совместимость с ком то куда же деваться. Если смотреть на Net то там AddRef, Release и не нужен из-за сборщика мусора, а вот с QueryInterface есть небольшая проблема,
если в Delphi есть директива Implements позволяющая реализовать некий интерфейс объектом являющимся полем объекта, то в Net ту должен в объекте реализовывать его полностью. Кроме того ссылки на методы интерфейса хранятся в VMT, а вот доступ к ним через InterfaceTable которая представляет массив с адресами (смещениями в VMT объекта) и доступ к ней осуществляется по индексу через ID интерфеса присвоенного ему в рантайме. А так как объетов может быть много то и памяти жрут достаточно много.
S>>>>>>Причем в Delphi.Net через хэлперы была достигнута полная их совместимость.
kuj>>>>>Что есть "хэлпер"?
S>>>> Это фича компилятора. Если он не видит метода у объекта он обращается к хэлперу этого класса и если там есть такой метод то вызывает его.
S>>>> http://www.rsdn.ru/Forum/Message.aspx?mid=548308&pg=1
kuj>>>Больше похоже на костыль.
S>> Как скажешь. Только за счет костылей полностью совместимый код с Net. И в чем костыли??? Это фича компилятора очень удобно когда нужно расширить код не прибегая к наследованию в том числе и saled классов.
kuj>А что, код можно расширять только наследованием? Агрегацию уже отменили?.. Или для ER-логики придумали нечто более эффективное?
И перекрывать все методы ????? Ради добавления 2-3. Кроме того твой любимый оверхэд ни к чему хорошему не ведет.
S>>>>>>Так при едином базовом классе в этих средах работа выделение памяти, уничтожение, RTTI, работа с типом намного упрощает компиляцию и получение информации о типе в рантайме.
kuj>>>>>Все это есть в MFC. Более того, есть полноценная бинарная сериализация объектов...
S>>>>>> Тенденция развития говорит об этом. Подход С++ отвергнут в угоду гибгости.
kuj>>>>>Наоборот — негибкости. Подумайте логически...
S>>>> Я уже попытался ответить. В любом случае переубеждать не собираюсь.
kuj>>>Давайте определимся с терминологией.
kuj>>>1. "Гибкость" характеризуется количеством вариантов решения. Согласны?
kuj>>>2. В С++ мы не привязаны к конкретной библиотеке — хотим используем MFC и пишем для Windows, хотим используем Linux Qt и пишем под X Window. Хотим — вообще не используем классы. Пишем процедурными методами.
kuj>>>В .NET и Delphi мы автоматически привязываемся к System.Object и Object, соответственно.
S>> Гибкость в создании сложной иерархии классов прежде всего,
kuj>Так с созданием иерархии классов в C++ нет особых проблем. Да и с гибкостью, кстати, тоже, потому что: а) множественное наследование,
kuj>б) шаблоны, в) пространства имен, г) перегрузка операторов.
Гибкость нужна прежде всего компилятору и ООП. Все что ты привел имеет слабое отношение к ООП и RTTI
S>>RTTI и уменьшение количества кода.
kuj>RTTI, кстати, подразумевает увеличение количества кода там, где можно обойтись строгой типизацией, на основе шаблонной специализации.
S>>Kylix тоже используется CLX.
kuj>Ах, CLX...

S>> Кроме того а кто мешает использовать статические методы????
kuj>Религия.

Не религия а фундамент на котром стоит Delphi. И не только
http://www.rsdn.ru/forum/Message.aspx?mid=567965&only=1
http://www.rsdn.ru/forum/Message.aspx?mid=565396&only=1
S>> Единая иерархия только требует поля со ссылкой на VMT (в Net еще на блок синхронизации который еще используется и при Objet.GetHashCode), плюс выделение памяти не в стеке (хотя и там можно, но грабли при передачи ссылки можно получить). И тебя эти затраты так смущают.
kuj>Смущают. Честно. Есть класс задач, где они излишни, то бишь порождают пресловутый overhead.
S>> А ручная гибкость уже никому не нужна в сложных системах.
kuj>Весьма спорно.
Хорошо у меня есть много классов работающих в 4 раза быстрее нетовских (написанных на Net), есть объектная надстройка над файлами 1С типизированный аналог "объектов" 1С скорость в 30 раз и выше в зависимости от сложности. Думаешь кому нибудь это нужно?????
К сожалению простота и стандартность для большинства залог здоровья. А скорость нужна для очень узкого круга задач.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, Курилка, Вы писали:

L>>>Линк дашь?

К>>Если бы был — дал бы

L>Значит отсебятина.

Вот это тоже отсебятина:
http://www.microsoft-watch.com/article2/0,4248,1274625,00.asp ?
(хотя там ключ. роль отдана Great Plains)

Вот ещё ссылочка интересная — http://www.businessframework.com/
(хотя сайт и не микрософтовский...)

Здравствуйте, Курилка, Вы писали:

К>Вот это тоже отсебятина:
К>http://www.microsoft-watch.com/article2/0,4248,1274625,00.asp ?
К>(хотя там ключ. роль отдана Great Plains)

Спасибо. На выходных обязательно посмотрю. Сейчас к сожалению на это ни времени ни возможности нет.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, VladD2, Вы писали:

kuj>>При том, что ATL в мире C++ куда как популярнее CBuilder`а. Речь о легкости осуществления перехода.

VD>Видимо я не очень доходчиво выразился.

ATL никакого отношения к С++ не имеет. Да и нет в нем никаких атрибутов. Атрибуты есть в КОМ и сепециальной надстройке VS.
В догонку почитайте еще это: ms-help://MS.MSDNQTR.2003APR.1033/dnmag01/html/attributes.htm

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, NoFate, Вы писали:

NF>Странные идею нужно реализовывать. Мне кажется, что именно они изменяют окружающую действительность.

Это романтика. На практике качественный софт — это продуманные и тщательно спроектированные решения. А это не совестимо со странностями. Другое дело, что идеи могут быть дерзкими и неординартыми. Но не странными!

NF> Спорить со вторым утверждением не буду. Я не встречал процессов рассыпания такого рода проектов. Возможно, потому, что всё, в чём участвовал не имело такого большого объёма или сложности.

А я видел. Сроки затягиваются так, что проект теряет свою актуальность.

NF>Согласен. Но что вы считаете более удобным, чем C++ средством? Я могу привести только C#.

Собствнно этого уже достаточно.

Шарп во многом луше С++, хотя и далек от идеало. Есть правда еще ресерч-языки, но им всем не хватает того или иного.

Думаю, что C# 2.0 в сочетании с нашим R#-ом будет как раз шагом к некому идеалу.

NF>Ну-у-у... Мелочи, а приятно. Да и преимущества C++, имхо, именно в не слишком жёстком контроле...

Нет. Это недостаток. К приемуществам можно отнести поддержку различных парадигм программирования.

VD>>Свобода о которой говришь ты — это лишь илюзия.
NF>А свобода — всегда иллюзия.

Тут не поспоришь.

NF>Приведите, пожалуйста, примеры подобных продуктов, написанных на Delphi.

Море финансового софта. Есть игры, редакторы и многое другое. За конкретными ссылками лучше обращаться на сайты ее фанатов.

NF>Мдя... Очень может быть. Оно и естественно. Прогресс не стоит на месте.

К сожалению, многеи программисты так сильно держится за старые, что вообще не признают все новое прогрессом. Тут в параллельной ветке С++-ники очень часто говорят, что тот же дотнет — это регрес.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, kuj, Вы писали:

VD>>Видимо я не очень доходчиво выразился.

ATL никакого отношения к С++ не имеет. Да и нет в нем никаких атрибутов. Атрибуты есть в КОМ и сепециальной надстройке VS.
kuj>В догонку почитайте еще это: ms-help://MS.MSDNQTR.2003APR.1033/dnmag01/html/attributes.htm

Спасибо. Я лет 5 от барабанил на ATL-е и кое что знаю он нем. Почитай лучше сам. Кстати, достаточно внимательно прочесть заголовок: C++ Attributes: Make COM Programming a Breeze with New Feature in Visual Studio .NET

Еще раз повторяю, все это не имеет никакого отношения к С++. Это расширения среды разработки от МС. К примеру, на GCC ты не сможешь скомпилировать все это.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, Serginio1, Вы писали:

VD>>Может не стоит обсуждать вопросы в которых не имешь полного понимания?
S> Читать внимательно надо. Я подтвердил. Но как быть с унсейвом. Ведь C++ практически весь на указателях. Или там повсеместно GC.Alloc и интероп????

Боюсь, тебя никто не понял.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, VladD2, Вы писали:

kuj>>При том, что ATL в мире C++ куда как популярнее CBuilder`а. Речь о легкости осуществления перехода.
VD>Видимо я не очень доходчиво выразился.

ATL никакого отношения к С++ не имеет.
Вас неверно информировали. Имеет. Он написан на C++.
VD>Да и нет в нем никаких атрибутов.
Есть. Называются они ATL Server Attributes. ms-help://MS.MSDNQTR.2003APR.1033/vcattrib/html/vclrfATLServerAttributes.htm
VD>Атрибуты есть в КОМ и сепециальной надстройке VS.
Атрибуты есть в IDL, в COM, в ATL и в компиляторе VC++. ms-help://MS.MSDNQTR.2003APR.1033/vcattrib/html/vcrefattributesbygroup.htm

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, kuj, Вы писали:

kuj>...Атрибуты есть в IDL, в COM, в ATL и в компиляторе VC++. ms-help://MS.MSDNQTR.2003APR.1033/vcattrib/html/vcrefattributesbygroup.htm

В общем, продолжим эту плодотворную беседу когда ты скомпилируешь этот "С++-код" на каком-нить gcc или С++Builder.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, VladD2, Вы писали:

kuj>>...Атрибуты есть в IDL, в COM, в ATL и в компиляторе VC++. ms-help://MS.MSDNQTR.2003APR.1033/vcattrib/html/vcrefattributesbygroup.htm

VD>В общем, продолжим эту плодотворную беседу когда ты скомпилируешь этот "С++-код" на каком-нить gcc или С++Builder.

Разве я где-то утверждал, что атрибуты есть в стандартном C++? Отнюдь. Будьте внимательнее.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, VladD2, Вы писали:

VD>Это романтика. На практике качественный софт — это продуманные и тщательно спроектированные решения. А это не совестимо со странностями. Другое дело, что идеи могут быть дерзкими и неординартыми. Но не странными!
Конечно. Но иногда мы имеем дело с исследовательской работой. Какой, например? Да хотя бы искусственный интеллект. Конкретно, взаимодействие нейронных сетей в рамках каких-либо условий. Здесь сложно что-либо заранее спроектировать. Вы согласны? При этом появляются и дерзкие, и неординарные, и странные идеи. Их не обязательно переносить на практику. Зачастую им там просто нет применения... Но тем не менее.

VD>Думаю, что C# 2.0 в сочетании с нашим R#-ом будет как раз шагом к некому идеалу.
Гм. Идеал — это то, к чему нужно стремиться... Он недостижим...

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Lloyd, Вы писали:

L>Просто я пытаюсь отслеживать информацию по Аксапте, и ничего о том, что ее будут портировать (именно портировать Аксапту, а не писать новую систему) на Нет, не слышал. Возможно я что-то упустил.

Представитель МС (Дмитрий Старостин) после PDC говорил что уже сейчас ведется работа по переводу Аксапты на MBF.

... << RSDN@Home 1.1.3 beta 2 (mobile station) >>

Здравствуйте, Serginio1, Вы писали:

S> если в Delphi есть директива Implements позволяющая реализовать некий интерфейс объектом являющимся полем объекта, то в Net ту должен в объекте реализовывать его полностью. Кроме того ссылки на методы интерфейса хранятся в VMT, а вот доступ к ним через InterfaceTable которая представляет массив с адресами (смещениями в VMT объекта) и доступ к ней осуществляется по индексу через ID интерфеса присвоенного ему в рантайме. А так как объетов может быть много то и памяти жрут достаточно много.

Попрошу не путать. Количество объектов на это не влияет, даже количество всех классов на это не влияет. На размер ITable влияет количество классов, реализующих интерфейсы и количество самих интерфейсов. Размер ITable конкретного класса равен максимальному порядковому номеру от старта программы реализуемых интерфейсов * 4. Поскольку часто используемые интерфейсы как правило загружаются раньше то большие ITable будут только у классов, реализующих редко используемые и поздно загруженные интерфейсы. В итоге расход памяти на itable в реальной программе очень небольшой.

... << RSDN@Home 1.1.3 beta 2 (mobile station) >>

Здравствуйте, Serginio1, Вы писали:

S>>> Еще раз в Net нет статических виртуальных методов,
kuj>>А зачем нужны статические виртуальные методы?

S> На них вся Delphi построена
А в LISP все построено на списочных структурах — разве это значит, что и в C# следует использовать такую методику? Вы так и не ответили на вопрос: зачем нужны статические виртуальные методы...
S>и компонентная модель (информация о типе, виртуальные конструкторы при создании объектов из метаклассов, пользовательская информация о типе ее расширение, в том числе и десериализация итд).
В .NET и без статических виртуальных методов компонентная модель живет и здравствует. И уж точно развита получше, чем в Delphi.
S>>>частично они перекрываются атрибутами но очень дорогой ценой,
kuj>>Каким же образом?
S> Attribute.GetCustomAttribute.
Пример можно?
S>То есть программирование с интерфейсами по технике такое же как и в Net.
Вы можете написать интерфейс, который не наследует IUnknown?
S> если в Delphi есть директива Implements позволяющая реализовать некий интерфейс объектом являющимся полем объекта, то в Net ту должен в объекте реализовывать его полностью. Кроме того ссылки на методы интерфейса хранятся в VMT, а вот доступ к ним через InterfaceTable которая представляет массив с адресами (смещениями в VMT объекта) и доступ к ней осуществляется по индексу через ID интерфеса присвоенного ему в рантайме. А так как объетов может быть много то и памяти жрут достаточно много.
Я бы сказал, копейки. Подумайте сами...
S>>> Как скажешь. Только за счет костылей полностью совместимый код с Net. И в чем костыли??? Это фича компилятора очень удобно когда нужно расширить код не прибегая к наследованию в том числе и saled классов.
kuj>>А что, код можно расширять только наследованием? Агрегацию уже отменили?.. Или для ER-логики придумали нечто более эффективное?
S> И перекрывать все методы ?????
Зачем перекрывать? Я про классическую агрегацию (см. UML).
S>Ради добавления 2-3. Кроме того твой любимый оверхэд ни к чему хорошему не ведет.
Не перекрывайте — не будет overhead`а.
S>>> Гибкость в создании сложной иерархии классов прежде всего,
kuj>>Так с созданием иерархии классов в C++ нет особых проблем. Да и с гибкостью, кстати, тоже, потому что: а) множественное наследование,
kuj>>б) шаблоны, в) пространства имен, г) перегрузка операторов.
S> Гибкость нужна прежде всего компилятору
Компилятору? Так ведь шаблоны. Если Вы это понимаете под "гибкостью".
S>и ООП. Все что ты привел имеет слабое отношение к ООП
Если исключить из рассмотрения шаблоны, то самое непосредственное.
S>и RTTI
Так ведь шаблоны во многих случаях избавляют нас от надобности использовать RTTI.
S>>> Кроме того а кто мешает использовать статические методы????
kuj>>Религия.

S> Не религия а фундамент на котром стоит Delphi. И не только
Ну вот, Вы сами ответили на свой вопрос.

S>>> А ручная гибкость уже никому не нужна в сложных системах.
kuj>>Весьма спорно.
S> Хорошо у меня есть много классов работающих в 4 раза быстрее нетовских (написанных на Net), есть объектная надстройка над файлами 1С типизированный аналог "объектов" 1С скорость в 30 раз и выше в зависимости от сложности. Думаешь кому нибудь это нужно?????
В Вашем классе задач, возможно, нет.
S> К сожалению простота и стандартность для большинства залог здоровья. А скорость нужна для очень узкого круга задач.
Так где же простота? Напишите, например, аналог этого на Delphi и еще раз подумайте о простоте:

#include "stdafx.h"
#include <list>
#include <hash_map>

int _tmain(int argc, _TCHAR* argv[])
{
    std::list< int > strList;
    strList.push_back(1);
    strList.push_back(2);
    strList.push_back(3);
    
    stdext::hash_map<TCHAR*, int> hashTable;
    hashTable["value 1"] = 1;
    hashTable["value 2"] = 2;
    hashTable["value 3"] = 3;

    std::list< int >::const_iterator strListIter = strList.begin();
    for(; strListIter != strList.end(); strListIter++)
    {
        std::cout << (*strListIter) << std::endl;
    }

    stdext::hash_map<TCHAR*, int>::const_iterator hashTableIter = hashTable.begin();
    for(; hashTableIter != hashTable.end(); hashTableIter++)
    {
        std::cout << "[" << hashTableIter->first << "] = " << hashTableIter->second << std::endl;
    }

    std::cout << hashTable["value 1"] << std::endl;
    std::cout << hashTable["value 2"] << std::endl;
    std::cout << hashTable["value 3"] << std::endl;

    return 0;
}

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, NoFate, Вы писали:

NF>Конечно. Но иногда мы имеем дело с исследовательской работой. Какой, например? Да хотя бы искусственный интеллект. Конкретно, взаимодействие нейронных сетей в рамках каких-либо условий. Здесь сложно что-либо заранее спроектировать. Вы согласны?

Нет. Ты описываешь разработку методом тыка. Я сам иногда на нее сваливась, но это не есть гуд. Идеи идеями. Продумывание же их реализации и реализация — это отдельные процессы. И в них скатываться на тык не стоит.

NF> При этом появляются и дерзкие, и неординарные, и странные идеи.

Дерзкие, не ординарные... согласен. Но странными идеи становятся тольео если плохо продуманы и изложены (плохо поняты в конце концов) или если они бессмысленны.

NF> Их не обязательно переносить на практику. Зачастую им там просто нет применения... Но тем не менее.

Ну, если идеи затрагивают фундаментальные знания, то наверно. А так все же лучше видеть все разумные идеи на практике.

NF>Гм. Идеал — это то, к чему нужно стремиться... Он недостижим...

А знашь почему он не достижим? Потму, что когда мы достигаем того, что когда-то считали идиалом, то начинаем видить новые горизонты к которым хочется стремиться. Так что важен не идеал, а стремление к нему.

ЗЫ

Здесь принято общаться на ты. На вы обычно переходят одновременно с переходом на личности.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, kuj, Вы писали:

kuj>Разве я где-то утверждал, что атрибуты есть в стандартном C++? Отнюдь. Будьте внимательнее.

С++ и описывается стандартом. Если приписывать к нему частные доработки, то можно договориться, до того, что в С++ давно есть сепер-мощные фичи, так как есть OpenC++.

Ни КОМ, ни расширения компиляторв, ни что иное не записанное в стандарте С++-ом не является.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, VladD2, Вы писали:

kuj>>Разве я где-то утверждал, что атрибуты есть в стандартном C++? Отнюдь. Будьте внимательнее.
VD>С++ и описывается стандартом. Если приписывать к нему частные доработки, то можно договориться, до того, что в С++ давно есть сепер-мощные фичи, так как есть OpenC++.
VD>Ни КОМ, ни расширения компиляторв, ни что иное не записанное в стандарте С++-ом не является.

Да, Вы несомненно правы, но речь-то шла немного о другом.
Напоминаю:

Ага наверное логичнее сравнивать Delphi/Net/Java vc C++. Так как у Net и у Delphi на много больше схожего и дельфисты в Net и Яве как рыбы в воде, чего не скажешь о сишниках.

Не знаю как у Вас, но среди моих знакомых и коллег нет ни одного "сишника", которому не приходилось бы работать с COM и ATL.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, VladD2, Вы писали:

kuj>>>Разве я где-то утверждал, что атрибуты есть в стандартном C++? Отнюдь. Будьте внимательнее.
VD>>С++ и описывается стандартом. Если приписывать к нему частные доработки, то можно договориться, до того, что в С++ давно есть сепер-мощные фичи, так как есть OpenC++.
VD>>Ни КОМ, ни расширения компиляторв, ни что иное не записанное в стандарте С++-ом не является.

kuj>Да, Вы несомненно правы, но речь-то шла немного о другом.
kuj>Напоминаю:
kuj>

kuj>Ага наверное логичнее сравнивать Delphi/Net/Java vc C++. Так как у Net и у Delphi на много больше схожего и дельфисты в Net и Яве как рыбы в воде, чего не скажешь о сишниках.

kuj>Не знаю как у Вас, но среди моих знакомых и коллег нет ни одного "сишника", которому не приходилось бы работать с COM и ATL.

А причем тут КОМ и АТЛ? Я работали и сними, и С++ и с Дельфи и даже с Явой (правда совсем чуть-чуть).

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, AndrewVK, Вы писали:

AVK>Представитель МС (Дмитрий Старостин) после PDC говорил что уже сейчас ведется работа по переводу Аксапты на MBF.

А чего ради, если через год-два обещают новую систему?

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Курилка, Вы писали:

L>>Значит отсебятина.

К>Вот это тоже отсебятина:
К>http://www.microsoft-watch.com/article2/0,4248,1274625,00.asp ?
К>(хотя там ключ. роль отдана Great Plains)

Ни слова об Аксапте.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Lloyd, Вы писали:

L>А чего ради, если через год-два обещают новую систему?

Рынок ERP штука весьма особая.

... << RSDN@Home 1.1.3 beta 2 (mobile station) >>

Здравствуйте, VladD2, Вы писали:

NF>> При этом появляются и дерзкие, и неординарные, и странные идеи.

VD>Дерзкие, не ординарные... согласен. Но странными идеи становятся тольео если плохо продуманы и изложены (плохо поняты в конце концов) или если они бессмысленны.
Пожалуй, я имел в виду плохо понятые идеи.

VD>Здесь принято общаться на ты. На вы обычно переходят одновременно с переходом на личности.

Не знал.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, Serginio1, Вы писали:

S>>>> Еще раз в Net нет статических виртуальных методов,
kuj>>>А зачем нужны статические виртуальные методы?

S>> На них вся Delphi построена
kuj>А в LISP все построено на списочных структурах — разве это значит, что и в C# следует использовать такую методику? Вы так и не ответили на вопрос: зачем нужны статические виртуальные методы...

Изучи исходники Delphi и сразу все станет ясно, зачем нужны виртуальные конструкторы, класс виртуальные методы итд.
В Net альтернатива им рефлексия и атрибуты отнюдь не быстрые.
S>>и компонентная модель (информация о типе, виртуальные конструкторы при создании объектов из метаклассов, пользовательская информация о типе ее расширение, в том числе и десериализация итд).
kuj>В .NET и без статических виртуальных методов компонентная модель живет и здравствует. И уж точно развита получше, чем в Delphi.
Живет и здравствуеи но с метаклассами здравствовала бы еще лучше. В Delphi.Net есть поддержка метаклассов.
S>>>>частично они перекрываются атрибутами но очень дорогой ценой,
kuj>>>Каким же образом?
S>> Attribute.GetCustomAttribute.
kuj>Пример можно?

http://www.rsdn.ru/forum/Message.aspx?mid=554256&only=1
S>>То есть программирование с интерфейсами по технике такое же как и в Net.
kuj>Вы можете написать интерфейс, который не наследует IUnknown?
Нет.
S>> если в Delphi есть директива Implements позволяющая реализовать некий интерфейс объектом являющимся полем объекта, то в Net ту должен в объекте реализовывать его полностью. Кроме того ссылки на методы интерфейса хранятся в VMT, а вот доступ к ним через InterfaceTable которая представляет массив с адресами (смещениями в VMT объекта) и доступ к ней осуществляется по индексу через ID интерфеса присвоенного ему в рантайме. А так как объетов может быть много то и памяти жрут достаточно много.
kuj>Я бы сказал, копейки. Подумайте сами...
Смотря сколько классов. В нормальных приложениях исчисляются десятками тысяч.
S>>>> Как скажешь. Только за счет костылей полностью совместимый код с Net. И в чем костыли??? Это фича компилятора очень удобно когда нужно расширить код не прибегая к наследованию в том числе и saled классов.
kuj>>>А что, код можно расширять только наследованием? Агрегацию уже отменили?.. Или для ER-логики придумали нечто более эффективное?
S>> И перекрывать все методы ?????
kuj>Зачем перекрывать? Я про классическую агрегацию (см. UML).
S>>Ради добавления 2-3. Кроме того твой любимый оверхэд ни к чему хорошему не ведет.
kuj>Не перекрывайте — не будет overhead`а.
S>>>> Гибкость в создании сложной иерархии классов прежде всего,
kuj>>>Так с созданием иерархии классов в C++ нет особых проблем. Да и с гибкостью, кстати, тоже, потому что: а) множественное наследование,
kuj>>>б) шаблоны, в) пространства имен, г) перегрузка операторов.
S>> Гибкость нужна прежде всего компилятору
kuj>Компилятору? Так ведь шаблоны. Если Вы это понимаете под "гибкостью".
S>>и ООП. Все что ты привел имеет слабое отношение к ООП
kuj>Если исключить из рассмотрения шаблоны, то самое непосредственное.
И еще в) пространства имен, г) перегрузка операторов ну никаким боком к ООП.
S>>и RTTI
kuj>Так ведь шаблоны во многих случаях избавляют нас от надобности использовать RTTI.
Да????
S>>>> Кроме того а кто мешает использовать статические методы????
kuj>>>Религия.

S>> Не религия а фундамент на котром стоит Delphi. И не только
kuj>Ну вот, Вы сами ответили на свой вопрос.

S>>>> А ручная гибкость уже никому не нужна в сложных системах.
kuj>>>Весьма спорно.
S>> Хорошо у меня есть много классов работающих в 4 раза быстрее нетовских (написанных на Net), есть объектная надстройка над файлами 1С типизированный аналог "объектов" 1С скорость в 30 раз и выше в зависимости от сложности. Думаешь кому нибудь это нужно?????
kuj>В Вашем классе задач, возможно, нет.
В моих задачах они используются. Скорее в Ваших.
S>> К сожалению простота и стандартность для большинства залог здоровья. А скорость нужна для очень узкого круга задач.
kuj>Так где же простота? Напишите, например, аналог этого на Delphi и еще раз подумайте о простоте:

kuj>

kuj>#include "stdafx.h"
kuj>#include <list>
kuj>#include <hash_map>

kuj>int _tmain(int argc, _TCHAR* argv[])
kuj>{
kuj>    std::list< int > strList;
kuj>    strList.push_back(1);
kuj>    strList.push_back(2);
kuj>    strList.push_back(3);
    
kuj>    stdext::hash_map<TCHAR*, int> hashTable;
kuj>    hashTable["value 1"] = 1;
kuj>    hashTable["value 2"] = 2;
kuj>    hashTable["value 3"] = 3;

kuj>    std::list< int >::const_iterator strListIter = strList.begin();
kuj>    for(; strListIter != strList.end(); strListIter++)
kuj>    {
kuj>        std::cout << (*strListIter) << std::endl;
kuj>    }

kuj>    stdext::hash_map<TCHAR*, int>::const_iterator hashTableIter = hashTable.begin();
kuj>    for(; hashTableIter != hashTable.end(); hashTableIter++)
kuj>    {
kuj>        std::cout << "[" << hashTableIter->first << "] = " << hashTableIter->second << std::endl;
kuj>    }

kuj>    std::cout << hashTable["value 1"] << std::endl;
kuj>    std::cout << hashTable["value 2"] << std::endl;
kuj>    std::cout << hashTable["value 3"] << std::endl;

kuj>    return 0;
kuj>}
kuj>

Написать типизированный hashTable 2 минуты, очереди пол минуты. Какие проблемы?????

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, AndrewVK, Вы писали:

AVK>Попрошу не путать. Количество объектов на это не влияет, даже количество всех классов на это не влияет. На размер ITable влияет количество классов, реализующих интерфейсы и количество самих интерфейсов. Размер ITable конкретного класса равен максимальному порядковому номеру от старта программы реализуемых интерфейсов * 4. Поскольку часто используемые интерфейсы как правило загружаются раньше то большие ITable будут только у классов, реализующих редко используемые и поздно загруженные интерфейсы. В итоге расход памяти на itable в реальной программе очень небольшой.
Насчет объектов оговорился. Разумеется речь шла о классах. Но есть круг задач где количество классов может исчислятся десятками тысяч, и так же количество интерфыейсов. Хотя во основном согласен.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, NoFate, Вы писали:

VD>>Дерзкие, не ординарные... согласен. Но странными идеи становятся тольео если плохо продуманы и изложены (плохо поняты в конце концов) или если они бессмысленны.
NF>Пожалуй, я имел в виду плохо понятые идеи.

Это совсем другое дело. К сожалению для того чтобы идеи были поняты иногда нужно чтобы общество было к ним подготовленно. Но во всех остальных случаях скорее виноваты те кто не сумел донести сви идеи до масс.

VD>>Здесь принято общаться на ты. На вы обычно переходят одновременно с переходом на личности.

NF>Не знал.

Об этом даже в правилах упамянуто. А смотреть как народ переходит на Вы после долгого общения на ты вообще умора.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, AndrewVK, Вы писали:

AVK>Рынок ERP штука весьма особая.

Конечно у этого рынка есть свои особенности. В частности — больший чем по отрасли консерватизм потребителей.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Serginio1, Вы писали:

S> Но есть круг задач где количество классов может исчислятся десятками тысяч, и так же количество интерфыейсов.

Есть, но я вроде как подробно объяснил почему это ничего особенно не решает. Впрочем десяток тысяч интерфейсов это перебор, я что то навскидку не могу представить для чего такое понадобится.

... << RSDN@Home 1.1.3 beta 2 (mobile station) >>

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Serginio1, Вы писали:

S>> Но есть круг задач где количество классов может исчислятся десятками тысяч, и так же количество интерфыейсов.

AVK>Есть, но я вроде как подробно объяснил почему это ничего особенно не решает. Впрочем десяток тысяч интерфейсов это перебор, я что то навскидку не могу представить для чего такое понадобится.
Если брать глобальную автоматизацию какого нибудь крупного горно-металлургического комбината то там и очень сложная и разнородная структура с оргромным количеством подразделений, взимосвязанных процессов (в том числе и физико-химических)
А так как я Обогатитель мне эта кухня хорошо известна.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, Serginio1, Вы писали:

S> Если брать глобальную автоматизацию какого нибудь крупного горно-металлургического комбината

Ну давай возьмем. Возьмем Парус 8, как самую тяжелую парусовую систему. Известно что в теперешнем состоянии существует менее 1500 разделов. Грубо можно считать что 1 раздел == 1 бизнес-класс. Итого, даже если предположить что на 1 бизнес-класс заводим два интерфейса десятки тысяч как то не получаются.

S>то там и очень сложная и разнородная структура с оргромным количеством подразделений, взимосвязанных процессов (в том числе и физико-химических)
S> А так как я Обогатитель мне эта кухня хорошо известна.

Ну тогда тебе должно быть хорошо известно что количество подразделений и процессов влияет только на размер справочника, но никак не на количество интерфейсов.

... << RSDN@Home 1.1.3 beta 2 (mobile station) >>

Не хочу вмешиваться..
Но может новую темку начать?
В этой уже чёрт ногу сломит..

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Serginio1, Вы писали:

S>> Если брать глобальную автоматизацию какого нибудь крупного горно-металлургического комбината

AVK>Ну давай возьмем. Возьмем Парус 8, как самую тяжелую парусовую систему. Известно что в теперешнем состоянии существует менее 1500 разделов. Грубо можно считать что 1 раздел == 1 бизнес-класс. Итого, даже если предположить что на 1 бизнес-класс заводим два интерфейса десятки тысяч как то не получаются.

S>>то там и очень сложная и разнородная структура с оргромным количеством подразделений, взимосвязанных процессов (в том числе и физико-химических)
S>> А так как я Обогатитель мне эта кухня хорошо известна.

AVK>Ну тогда тебе должно быть хорошо известно что количество подразделений и процессов влияет только на размер справочника, но никак не на количество интерфейсов.
Да но каждый элемент справочника может обладать отдельным набором свойств. Так как и спиртным занимался то вина имеют свой набор, водка тоже итд. Если правильно классифицировать то набирается оочень много. А разного рода реагенты, присадки, катализаторы итд применяемые в ГМК это еще та песня. И это только по классификаторам. А если брать еще факторы влияющие на процесс добачи руды ее переработки (обогащения и металлургических процессов), химические лаборатории, оборудование, запчасти, расходные материалы итд. И каждое подразделение представляет собой огромное производство. Но обычно каждое подразделение не ведет полный учет а разбивается на подотделы а в в подразделениях и головном ведется только консолидированный учет (иногда даже на уровне Ёкселевских файлов). Но если все слить воедино то уверяю 10 тысяч будет даже мало.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, Serginio1, Вы писали:

AVK>>Ну тогда тебе должно быть хорошо известно что количество подразделений и процессов влияет только на размер справочника, но никак не на количество интерфейсов.
S> Да но каждый элемент справочника может обладать отдельным набором свойств.

Рассказать как это обычно делается?

S>Так как и спиртным занимался то вина имеют свой набор, водка тоже итд.

Т.е. ты всерьез веришь в то что есть такие системы где на каждый элемент справочника свой интерфейс?

... << RSDN@Home 1.1.3 beta 2 (mobile station) >>

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Serginio1, Вы писали:

AVK>>>Ну тогда тебе должно быть хорошо известно что количество подразделений и процессов влияет только на размер справочника, но никак не на количество интерфейсов.
S>> Да но каждый элемент справочника может обладать отдельным набором свойств.

AVK>Рассказать как это обычно делается?
Как обычно я знаю. Но обычно при детальном учете строится куча подчиненных справочников.

S>>Так как и спиртным занимался то вина имеют свой набор, водка тоже итд.

AVK>Т.е. ты всерьез веришь в то что есть такие системы где на каждый элемент справочника свой интерфейс?
Не на каждый, а на группу. Но элемент может принадлежать к нескольким группам. А этих групп в ГМК огромное количество.
Все зависит от детальности учета.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, AndrewVK, Вы писали:

AVK>Рассказать как это обычно делается?

Расскажи...

Здравствуйте, Serginio1, Вы писали:

AVK>>Т.е. ты всерьез веришь в то что есть такие системы где на каждый элемент справочника свой интерфейс?
S> Не на каждый, а на группу. Но элемент может принадлежать к нескольким группам. А этих групп в ГМК огромное количество.
S> Все зависит от детальности учета.
Еще в догоночку, как то знакомые орлы решили сделать сайт с характеристиками продаваемой аппаратуры, но различий в атрибутах описателей оказалось столько, что они плюнули на это дело. А что говорить с автозапчастями, фармокологией.
А во многом это нужно для поиска, классификации, определения похожести, корреляции продаваемости от ассортимента итд. Кстати в КИС на такие факторы и классификацию уделяют большое внимание.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, Serginio1, Вы писали:

AVK>>Рассказать как это обычно делается?
S> Как обычно я знаю. Но обычно при детальном учете строится куча подчиненных справочников.

Но не десятки тысяч же!

AVK>>Т.е. ты всерьез веришь в то что есть такие системы где на каждый элемент справочника свой интерфейс?
S> Не на каждый, а на группу.

И такое тоже редко бывает по одной простой причине — для добавления новой группы нужно писать код. А это, как бы поприличнее выразится, кустарщина.

S>Но элемент может принадлежать к нескольким группам. А этих групп в ГМК огромное количество.
S> Все зависит от детальности учета.

От детальности учета зависит размер проводок, но никак не количество интерфейсов.

Вобщем надоел мне этот разговор ни о чем — есть хоть одна реальная система, содержащая одновременно в активном состоянии в пределах одного процесса десятки тысяч интерфейсов?

... << RSDN@Home 1.1.3 beta 2 (mobile station) >>

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Serginio1, Вы писали:

AVK>>>Рассказать как это обычно делается?
S>> Как обычно я знаю. Но обычно при детальном учете строится куча подчиненных справочников.

AVK>Но не десятки тысяч же!

AVK>>>Т.е. ты всерьез веришь в то что есть такие системы где на каждый элемент справочника свой интерфейс?
S>> Не на каждый, а на группу.

AVK>И такое тоже редко бывает по одной простой причине — для добавления новой группы нужно писать код. А это, как бы поприличнее выразится, кустарщина.
А кудаже деваться нашей огромной армии????

S>>Но элемент может принадлежать к нескольким группам. А этих групп в ГМК огромное количество.
S>> Все зависит от детальности учета.

AVK>От детальности учета зависит размер проводок, но никак не количество интерфейсов.
Классификаторы номенклатуры, материалов не относятся к проводкам, это относится к аналитическому (количественному, суммовому) учету в различных разрезах.

AVK>Вобщем надоел мне этот разговор ни о чем — есть хоть одна реальная система, содержащая одновременно в активном состоянии в пределах одного процесса десятки тысяч интерфейсов?
Наверное можно привести такие компании как Боинг, химические, фармоклогические концерны. Лучше спросить у знатоков смаллталка они приводили похожие цифры.
И реально зная производство такое возможно, правда и стоимость таких систем десятки миллионов уе.
Но обычно идут через дробление и консолидации синтетики . Комплексная 1С тоже около тысячи насчитывается но она далеко не все факторы учитывает.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, AndrewJD, Вы писали:

AVK>>Рассказать как это обычно делается?

AJD>Расскажи...

Справочником свойств (Коллекцией свойств (возможно полиморфной) в терминах ООП)

... << RSDN@Home 1.1.3 beta 2 (mobile station) >>

Здравствуйте, Serginio1, Вы писали:

S> Еще в догоночку, как то знакомые орлы решили сделать сайт с характеристиками продаваемой аппаратуры, но различий в атрибутах описателей оказалось столько, что они плюнули на это дело.

Это не аргумент

S> А что говорить с автозапчастями,

О, это делал. Никаких десятков тысяч интерфейсов, смею тебя уверить.

S> фармокологией.

А там что? Там с точки зрения автоматизации вобще все довольно примитивно.

S> А во многом это нужно для поиска, классификации, определения похожести, корреляции продаваемости от ассортимента итд.

Отлично. Не вижу зачем для этого десятки тысяч интерфейсов.

S> Кстати в КИС на такие факторы и классификацию уделяют большое внимание.

Да, разумеется. ВОт только почему то ни в одной реальной КИС я такого количества интерфейсов не встречал. Не подскажешь почему?

... << RSDN@Home 1.1.3 beta 2 (mobile station) >>

Здравствуйте, Serginio1, Вы писали:

AVK>>Вобщем надоел мне этот разговор ни о чем — есть хоть одна реальная система, содержащая одновременно в активном состоянии в пределах одного процесса десятки тысяч интерфейсов?
S> Наверное можно привести такие компании как Боинг,

Наверное не катит, не надо гадать на кофейной гуще. Впрочем для Боинга думаю потребления памяти системой таковы, что лишние несколько сотен килобайт на itable ни на что не влияют.

... << RSDN@Home 1.1.3 beta 2 (mobile station) >>

Здравствуйте, VladD2, Вы писали:

VD>Об этом даже в правилах упамянуто. А смотреть как народ переходит на Вы после долгого общения на ты вообще умора.
Хех. Надо бы почитать правила

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Serginio1, Вы писали:

S>> Еще в догоночку, как то знакомые орлы решили сделать сайт с характеристиками продаваемой аппаратуры, но различий в атрибутах описателей оказалось столько, что они плюнули на это дело.

AVK>Это не аргумент

S>> А что говорить с автозапчастями,

AVK>О, это делал. Никаких десятков тысяч интерфейсов, смею тебя уверить.
Смотря как делал. Если брать каталоги запчастей к разного рода иномарок, то классификаторов там огромная куча. Это не относится к учету а к поиску нужных деталей. Конечно 10 тысяч это черезчур.
S>> фармокологией.

AVK>А там что? Там с точки зрения автоматизации вобще все довольно примитивно.
Это с точки зрения автоматизации учета, но никак не классификации товара. Так как групп препаратов очень много со всоим набором свойств.

S>> А во многом это нужно для поиска, классификации, определения похожести, корреляции продаваемости от ассортимента итд.

AVK>Отлично. Не вижу зачем для этого десятки тысяч интерфейсов.
Все зависит от количества групп классификаторов. Это только то что касается учета. Но есть еще и программные библиотеки
Смотрим на Ёксель ХП то там насчитывается порядка 400-500 интерфейсов. А если ссумировать весь Net????
И в большом приложении могут использоваться практически весь набор.
S>> Кстати в КИС на такие факторы и классификацию уделяют большое внимание.

AVK>Да, разумеется. ВОт только почему то ни в одной реальной КИС я такого количества интерфейсов не встречал. Не подскажешь почему?
Да сложно все это. Упрощение залог здоровья. Тем более, что такого рода системы универсальны, и далеки от реальных потребностей предприятий.
Как то читал, что Банк заказал IBM систему учета стоимостью под миллиард.
В любом случае 10 тысяч это не рядовое приложение, но вполне вероятно.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, Serginio1, Вы писали:

S> Все зависит от количества групп классификаторов. Это только то что касается учета. Но есть еще и программные библиотеки
S> Смотрим на Ёксель ХП то там насчитывается порядка 400-500 интерфейсов. А если ссумировать весь Net????
Уточну порядка 700. В файле ExcelXP.pas такой образец {\w+\-\w+\-\w+\-\w+\-\w+}' встречается 1452 но за вычетом диспинтерфесов и прочей лабуды .

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, Dimonka, Вы писали:

D>В этой уже чёрт ногу сломит..

Янус пока чёрта за рога придерживает.

Но если модераторы не будут модерить...

Ты начни, если есть что интересное, народ и потянется...

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, VladD2, Вы писали:

VD>А смотреть как народ переходит на Вы после долгого общения на ты вообще умора.

Эта не умора, это модерировать надо. С отправкой в бан. Потому как это они перед нашими глазами ругаются, кроят друг друга "разрешённым матом". А мы в упор не видим.

... << RSDN@Home 1.1.3 beta 2 >>

Здравствуйте, Serginio1, Вы писали:

S>>>>> Еще раз в Net нет статических виртуальных методов,
kuj>>>>А зачем нужны статические виртуальные методы?

S>>> На них вся Delphi построена
kuj>>А в LISP все построено на списочных структурах — разве это значит, что и в C# следует использовать такую методику? Вы так и не ответили на вопрос: зачем нужны статические виртуальные методы...
S> Изучи исходники Delphi и сразу все станет ясно, зачем нужны виртуальные конструкторы, класс виртуальные методы итд.
Нет, спасибо. Изучать исходники Делфи не входит в сферу моих интересов и обязаностей. Разве что, как пример неудачной архитектуры.
S> В Net альтернатива им рефлексия и атрибуты отнюдь не быстрые.

S>>>и компонентная модель (информация о типе, виртуальные конструкторы при создании объектов из метаклассов, пользовательская информация о типе ее расширение, в том числе и десериализация итд).
kuj>>В .NET и без статических виртуальных методов компонентная модель живет и здравствует. И уж точно развита получше, чем в Delphi.
S> Живет и здравствуеи но с метаклассами здравствовала бы еще лучше.
Возможно, хотя я бы не был так категоричен.
S>В Delphi.Net есть поддержка метаклассов.
И что? Delphi.Net не соответствует CLS? Что в этом хорошего?
S>>>>>частично они перекрываются атрибутами но очень дорогой ценой,
kuj>>>>Каким же образом?
S>>> Attribute.GetCustomAttribute.
kuj>>Пример можно?
S> http://www.rsdn.ru/forum/Message.aspx?mid=554256&only=1
А пример с Attribute.GetCustomAttribute, заменяющий статические виртуальные методы где?

S>>>То есть программирование с интерфейсами по технике такое же как и в Net.
kuj>>Вы можете написать интерфейс, который не наследует IUnknown?
S> Нет.
Значит не такое же.
S>>> если в Delphi есть директива Implements позволяющая реализовать некий интерфейс объектом являющимся полем объекта, то в Net ту должен в объекте реализовывать его полностью. Кроме того ссылки на методы интерфейса хранятся в VMT, а вот доступ к ним через InterfaceTable которая представляет массив с адресами (смещениями в VMT объекта) и доступ к ней осуществляется по индексу через ID интерфеса присвоенного ему в рантайме. А так как объетов может быть много то и памяти жрут достаточно много.
kuj>>Я бы сказал, копейки. Подумайте сами...
S> Смотря сколько классов. В нормальных приложениях исчисляются десятками тысяч.
Да хоть сотнями — все-равно копейки. Подумайте.
S>>>>> Гибкость в создании сложной иерархии классов прежде всего,
kuj>>>>Так с созданием иерархии классов в C++ нет особых проблем. Да и с гибкостью, кстати, тоже, потому что: а) множественное наследование,
kuj>>>>б) шаблоны, в) пространства имен, г) перегрузка операторов.
S>>> Гибкость нужна прежде всего компилятору
kuj>>Компилятору? Так ведь шаблоны. Если Вы это понимаете под "гибкостью".
S>>>и ООП. Все что ты привел имеет слабое отношение к ООП
kuj>>Если исключить из рассмотрения шаблоны, то самое непосредственное.
S> И еще в) пространства имен,
Это тоже ООП — с помощью пространств имен выполняется разрешение конфликтов имен.
S>г) перегрузка операторов ну никаким боком к ООП.
А если подумать? Оператор сам по себе ничего не значит. Его значение сугубо прикладное. А т.к. оператор имеет непосредственное отношение к понятию "класс", то и к ООП он имеет отношение. Как минимум косвенное.
S>>>и RTTI
kuj>>Так ведь шаблоны во многих случаях избавляют нас от надобности использовать RTTI.
S> Да????
Естественно. Простейший пример: list<int> VS TList — в первом случае RTTI не нужен, во-втором нужен.
S>>>>> А ручная гибкость уже никому не нужна в сложных системах.
kuj>>>>Весьма спорно.
S>>> Хорошо у меня есть много классов работающих в 4 раза быстрее нетовских (написанных на Net), есть объектная надстройка над файлами 1С типизированный аналог "объектов" 1С скорость в 30 раз и выше в зависимости от сложности. Думаешь кому нибудь это нужно?????
kuj>>В Вашем классе задач, возможно, нет.
S> В моих задачах они используются.
Сами себе противоречите.

S>Скорее в Ваших.
А что Вы можете знать про мой класс задач?
S>>> К сожалению простота и стандартность для большинства залог здоровья. А скорость нужна для очень узкого круга задач.
kuj>>Так где же простота? Напишите, например, аналог этого на Delphi и еще раз подумайте о простоте:

kuj>>

kuj>>#include "stdafx.h"
kuj>>#include <list>
kuj>>#include <hash_map>

kuj>>int _tmain(int argc, _TCHAR* argv[])
kuj>>{
kuj>>    std::list< int > strList;
kuj>>    strList.push_back(1);
kuj>>    strList.push_back(2);
kuj>>    strList.push_back(3);
    
kuj>>    stdext::hash_map<TCHAR*, int> hashTable;
kuj>>    hashTable["value 1"] = 1;
kuj>>    hashTable["value 2"] = 2;
kuj>>    hashTable["value 3"] = 3;

kuj>>    std::list< int >::const_iterator strListIter = strList.begin();
kuj>>    for(; strListIter != strList.end(); strListIter++)
kuj>>    {
kuj>>        std::cout << (*strListIter) << std::endl;
kuj>>    }

kuj>>    stdext::hash_map<TCHAR*, int>::const_iterator hashTableIter = hashTable.begin();
kuj>>    for(; hashTableIter != hashTable.end(); hashTableIter++)
kuj>>    {
kuj>>        std::cout << "[" << hashTableIter->first << "] = " << hashTableIter->second << std::endl;
kuj>>    }

kuj>>    std::cout << hashTable["value 1"] << std::endl;
kuj>>    std::cout << hashTable["value 2"] << std::endl;
kuj>>    std::cout << hashTable["value 3"] << std::endl;

kuj>>    return 0;
kuj>>}
kuj>>

S> Написать типизированный hashTable 2 минуты,
Докажите. А потом посмотрим на ваш код, на его читабельность, на его эффективность. Кстати, интересно так же узнать, как без перегрузки операторов Вы повторите алгоритм работы operator[]...
S>очереди пол минуты.
А с каких это пор двусвязный список стал очередью? Он как минимум дек. Хотя и деком эту структуру никак нельзя назвать. Это именно двусвязный список.
S>Какие проблемы?????
1) читабельность кода, 2) эффективность реализации, 3) целесообразность (изобретаем велосипед), 4) потенциальный источник дополнительных ошибок (в основном алгоритмического типа).

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Serginio1, Вы писали:

S>>> А что говорить с автозапчастями,

AVK>>О, это делал. Никаких десятков тысяч интерфейсов, смею тебя уверить.
S> Смотря как делал.

Хорошо.

S> Если брать каталоги запчастей к разного рода иномарок, то классификаторов там огромная куча. Это не относится к учету а к поиску нужных деталей.

Мужик, ты не понял. Я делал реальную систему для сети магазинов и складов, торгующих запчастями. Не надо мне рассказывать что там и как, это я сам могу тебе подробно рассказать.

S>Конечно 10 тысяч это черезчур.

А чего тогда споришь?

AVK>>А там что? Там с точки зрения автоматизации вобще все довольно примитивно.
S> Это с точки зрения автоматизации учета, но никак не классификации товара. Так как групп препаратов очень много со всоим набором свойств.

И при чем тут количество интерфейсов?

AVK>>Отлично. Не вижу зачем для этого десятки тысяч интерфейсов.
S> Все зависит от количества групп классификаторов.

Не зависит.

S>Но есть еще и программные библиотеки
S> Смотрим на Ёксель ХП то там насчитывается порядка 400-500 интерфейсов.

Причем если выкинуть порождения сна разума с номерками в конце то их будет еще меньше. Ну и где десятки тысяч?

S> А если ссумировать весь Net????

Суммируй.

AVK>>Да, разумеется. ВОт только почему то ни в одной реальной КИС я такого количества интерфейсов не встречал. Не подскажешь почему?
S> Да сложно все это. Упрощение залог здоровья.

О как. Так нафига ты рассказываешь байки про ужасное пожирание памяти в itable? Опять сферический конь в вакууме?

S> Тем более, что такого рода системы универсальны, и далеки от реальных потребностей предприятий.

Я видел и неуниверсальные, нет там такого количества интерфейсов.

S> Как то читал, что Банк заказал IBM систему учета стоимостью под миллиард.
S> В любом случае 10 тысяч это не рядовое приложение, но вполне вероятно.

Вобщем я уже понял. Ты не видел, просто трепишься.

... << RSDN@Home 1.1.3 beta 2 (mobile station) >>

Здравствуйте, kuj, Вы писали:

kuj>Изучать исходники Делфи <...> как пример неудачной архитектуры.
+

By the grace of God Almighty
And the pressures of a marketplace
The human race has civilized itself
It's a miracle

Здравствуйте, AndrewVK, Вы писали:

AVK>Мужик, ты не понял. Я делал реальную систему для сети магазинов и складов, торгующих запчастями. Не надо мне рассказывать что там и как, это я сам могу тебе подробно рассказать.
А у меня уже сделано

S>>Конечно 10 тысяч это черезчур.

AVK>А чего тогда споришь?

AVK>>>А там что? Там с точки зрения автоматизации вобще все довольно примитивно.
S>> Это с точки зрения автоматизации учета, но никак не классификации товара. Так как групп препаратов очень много со всоим набором свойств.

AVK>И при чем тут количество интерфейсов?
А это уже как проектировать. Применение интерфейсов с точки зрения программирования предпочительней, применять к набору свойств именно интерфейсы.
AVK>>>Отлично. Не вижу зачем для этого десятки тысяч интерфейсов.
S>> Все зависит от количества групп классификаторов.

AVK>Не зависит.
Опять же все зависит от проектирования. В 1С вообще нет интерфейсов, но возможность их применения повысила бы производительность труда.
S>>Но есть еще и программные библиотеки
S>> Смотрим на Ёксель ХП то там насчитывается порядка 400-500 интерфейсов.

AVK>Причем если выкинуть порождения сна разума с номерками в конце то их будет еще меньше. Ну и где десятки тысяч?
Там их 1400 уже сократил до минимума. Так это один Ёксель. Возможно применение и других монстроидальных программ.
S>> А если ссумировать весь Net????

AVK>Суммируй.
А смысл.
AVK>>>Да, разумеется. ВОт только почему то ни в одной реальной КИС я такого количества интерфейсов не встречал. Не подскажешь почему?
S>> Да сложно все это. Упрощение залог здоровья.

AVK>О как. Так нафига ты рассказываешь байки про ужасное пожирание памяти в itable? Опять сферический конь в вакууме?
Хочу стать Сказочником. Просто не очень красивое решение, но быстрое и ничего против не имею.
S>> Тем более, что такого рода системы универсальны, и далеки от реальных потребностей предприятий.

AVK>Я видел и неуниверсальные, нет там такого количества интерфейсов.

S>> Как то читал, что Банк заказал IBM систему учета стоимостью под миллиард.
S>> В любом случае 10 тысяч это не рядовое приложение, но вполне вероятно.

AVK>Вобщем я уже понял. Ты не видел, просто трепишься.
Ну ради этого и существуют форумы. Тем более тема во флейме.
А вообщето спор был о возможности.

... << RSDN@Home 1.1.0 stable >>

Здравствуйте, kuj, Вы писали:

S>> Изучи исходники Delphi и сразу все станет ясно, зачем нужны виртуальные конструкторы, класс виртуальные методы итд.
kuj>Нет, спасибо. Изучать исходники Делфи не входит в сферу моих интересов и обязаностей. Разве что, как пример неудачной архитектуры.
Да уж такое высказывание говорит о многм. И зачем это позвольте Вас спросить M$ переманила к себе Андреаса Хейлсберга, после которой потянулись суды и в итоге M$ скупила 10% акций Борланда, заключило патентное соглашение в итоге выплатив порядка 100 миллионов $. Не плохая цена за неудачную архитектуру.

... << RSDN@Home 1.1.0 stable >>

G_>>Это не в тему, вообще-то.

Но зачем кричать про революционные идеи в .NET

AVK>Вот ведь забавная штука — этот аргУмент я слышу регулярно. Где в этом топике кричали про революционные идеи .NET?

Я не про этот топик, а про MS говорю.

G_>>, если a) _НИЧЕГО_НОВОГО_ в .NET нету. _Н И Ч Е Г О_.
G_>>b) в .NET нет ни одной идеи, которая была _придумана в MS_.

AVK>Ну и? Что дальше?

kuj>>>PreProcessMessage позволяет обработать сообщение непосредственно перед dispatch.

G_>>Я не понимаю о чем Вы.

AVK>Можно обработать сообщение до того как оно попало в WndProc конкретного окна.

И? Приведенный мною код именно это и делает.

kuj>>>Модульная схема компиляции и линковки? А как это?

G_>>C++ компилирует файлы, Delphi компилирует модули.

AVK>

AVK> 5 баллов за компиляцию модулей, и еще 5 за компиляцию модулей, которые не файлы. В юмор, однозначно.

Речь о том, что в C++ изначально заложена концепция файловой компиляции, все файлы равнозначны для линкера. Хедер по сути несет
только объявления, но не говорит линкеру о том, где искать тело функции.

В дельфи и других модульных системах есть понятие модуля. при этом когда один из модулей использует другой (через uses) линкер
знает где искать и тело и объявления функции. Соотвественно есть взаимозависимость модулей и отсюда возможность частичной компиляции и пр.

По-моему, очевидно, что как не оптимизируй схему файловой компиляции+линковки она никогда не будет быстрее модульной.

S>>> Предпочитаю свои классы, т.к. стандартные как правило ограничены.

G_>>Это спор разработчика-одиночки и разработчика-члена-команды. Понятно, что свои компоненты ближе к сердцу и можно делать с ними все что
G_>>угодно, только иногда как ни странно важна стандартизация и абсолютная безглючность, проверенная временем.

G_>>Я тоже написал в свое время Б-дерево, идея возникла за 15 минут, реализация — за день. Только вот
G_>>_нормальное_работающее_Б-дерево_, охваченное итераторами, оптимизированное где нужно, с самопроверкой и пр. взошло не один месяц спустя.

S> Когда опираешься на собственные реализации алгоритмов и проверенные временем то они становятся для меня уже стандартными.

Для Вас — да! Но не для остальных разработчиков. Стандартизация имеет свои прелести, хотя и немного ограничивает.

S> Кстати многие сишникиеи простейших алгоритмов не знают. Зато знают вектор map итд. А переходя на C# руки опускаются.

Отчего?

G_>>Мое самое оптимизированное Б-дерево все равно было медленнее map примерно в 1.5 раза.
S> Значит таков алгоритм или его реализация. А под мап можно подогнать и Хэш таблицы и BitArray и B+ деревья и просто массив и у всех есть плюсы и минусы и своя область применения.

Я о том и говорю. Что в STL, как правило, зашиты самые удачные алгоритмы, к тому же многократно проверенные.

G_>>>>То, что STL появилась на свет и успешно существует и очень многими используется доказывает мою правоту.
S>>> Пользоваться можно чем угодно в том числе и генераторами кода.
S>>> А против стандарта и корпоративного кодирования ничего против не имею, только скучно.

G_>>Да уж, зато вставить в свою программу глючный компонент, обрушить пару сотен терминалов в самый разгар торгов,
G_>>получить сотню одновременных звонков на предмет невозможности торговать от клиентов, кучу претензий, удары по всем
G_>>частям тела от хедпдеска и от начальства и от начальства начальства — быстро начинать править код, каждый
G_>>5 сек. дергаемый словами "ну что готово" и "там опять все упало", быстро раздать это все какой-то паре сотен клиентов — вот ерунда-то! — это конечно не скучно, это очень весело!!!!!

S> Значит не надо делать глючные компоненты. А своих багов добавить и простейший код всегда пожалуйста, а во многом юзерский код оказывается намного алгоритмически сложнее чем стандартные библиотеки где кода 10 строчек.
S> Не ошибается тот кто ничего не делает, а кривизны в стандартных библиотеках хватает выше крыши как в Delphi, Net, Java.
S> Нет кривизны только в STL !!!!!!

G_>>Я тоже заметил, что в теории программирования все всегда просто. Взять алгоритм да и внедрить его.
G_>>Откуда берутся глючные программы совершенно непонятно...)

VD>А это из-за велосипидистов.

Не хотят они взять чужой алгорим, а хотят сами по граблям полазить.

Я имел в виду другое. Что корректная реализация сложного алгоритма непростая задача сама по себе.

G_>>Вот это и плохо. Borland обязана была что предпринять на эту тему.

VD>Ну, а без Борланда, что трава не расти? Что только в Борланде грамотные программисты есть?

Я немного о другом.

VD>>>Ага. А так же ее доказывает. Наличие МФЦ, АТЛ-а, буста, и других библиотек содержащих свои коллекции.

G_>>Что конкретно плохо в STL и чем она вас не устраивает?

VD>Да многим. Есть не продуманные интерфейсы, как у мап-а.

В чем непродуманность?

Не нравится странные названия многих методов. Не нравится, что что коллекции не имеют полноценного набора методов (все в отдельных функциях).
Не нравится примитивность коллекций (могли бы реализовать и блее продвинутые вещи вроде Б+-деревьев и хэш-таблиц, хотя в нестандартных расширениях кое-что есть.)

Ну все-таки Б+-деревья не каждый день нужны. А вот map это must have.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Gregory_krovosos, Вы писали:

VD>>>Вообще-то в дельфи есть тип object и record.

G_>>У них нет конструктора/деструктора. Это просто выделить кусок памяти с именованными полями на стеке.

AVK>У object есть.

Я имел в виду, что они не вызываются при размещении объекта на стеке и следовательно object бесполезен.

VD>>>Так это наличие автоматического вызова деструктора/финалайзера. В Шарпе этого тоже нет. Но есть IDisposeble и инструкция using.

G_>>Да, действительно.

G_>>Немного отступая от темы — непонятно зачем вC# делать так неудобно?????

AVK>Потому что GC

G_>>Это совместимость с какой-то предыдущей OLE-байдой?

AVK>Нет

G_>>Почему нельзя было для любого класса просто дернуть деструктор

AVK>Потому что деструктора нет.

Ну есть же finalize, зачем нужно воротить?

G_>> вместо наследования IDisposable,

AVK>Реализации, не наследования.

Разумеется.

G_>> переопределения двух методов

AVK>Каких двух методов?

Сори, одного. Ну чтобы понять что я имел в виду надо просто посмотреть пример в MSDN для IDisposable.
Вместо упрощения — усложнение кода.

G_>>Спасибо за инфу, но это все таки хеш. А нужно AVL-дерево или аналог.

VD>Ты говорил про мап. Мап самым эффективным образом реализуется на хэш-таблице.

Ну если элементов не много, то да.

VD>С деревьями у борланда фигово.

G_>>Порядок строк важен!

VD>А два листа чем не устраивают?

Ну понятно, что можно написать все что угодно

Речь идет о простом решении.

G_>>У них нет конструктора/деструктора. Это просто выделить кусок памяти с именованными полями на стеке.

VD>А что толку в деструкторах в Дельфи? Один фиг вручную вызывать.

Я о том же.

G_>>Немного отступая от темы — непонятно зачем вC# делать так неудобно????? Это совместимость с какой-то предыдущей OLE-байдой?
G_>>Почему нельзя было для любого класса просто дернуть деструктор вместо наследования IDisposable, переопределения двух методов и пр.
G_>>Я не понимаю...

VD>Да в общем то сложности никакой нет. Метод переопределят нужно только один.

VD>А почему нет деструктора... Сдается мне это в погоне за чистотой языка. В общем, догмы. Хотя имея трехлетний опыт программирования на Шарпе могу со всей отвественностью заявить, что проблем в этом нет никакий. Финализация нужна крайне редко. И гед она нужна обычно достаточно using-а.

Ну я с шарпом только начал разбираться, но думаю что ты прав в чем-то. Обычно в деструкторе чистят мусор, а здесь это делается автоматически.

G_>>Как бы не вышло опять гладко в теории, а на практике...

VD>Да вот как бы от Дельфи в свое время мы отказались в виду ужасного количества глюков в ВЦЛ-е (еще во времена 4-ой версии), а дотнет вроде как удовлетворяет.

Я с 4-кой не работал, начал с 1-ой версии дельфи

и потом перепрыгнул сразу на 5-ю

VCL конечно не идеал, но в целом более менее.
Глюков (явных) заметил всего несколько штук, при этом они исправляются.

G_>>Я честно говоря не понял — какой кайф? Хочешь .NET — берешь VS .NET + C# и пишешь. Хочешь нейтив код — берешь Delphi 7 и пишешь.

VD>Ну, если ты в основном писал на Дельфи, то кайф в том что не нужно переучиваться.

G_>>Смысл появление Delphi .NET от меня ускользнул...Ведь и так можно в C# запускать нейтив код...
G_>>Создать очередную всеобъемлющую супер-пупер-унаследованную библиотеку классов?
G_>>Не понял я...

VD>Думаю, что решение о переводе Дельфи на дотнет было принято не от болды. Скорее всего ребята поняли, что МС серьезно переориентируется на него и решили не упускать шанса.

Что ж посмотрим, что выйдет из этого.

PS Не в тему — как шарп относится к ресурсам? В смысле работащее приложение много жрет?

Здравствуйте, Gregory_krovosos, Вы писали:

G_>>>Почему нельзя было для любого класса просто дернуть деструктор

AVK>>Потому что деструктора нет.

G_>Ну есть же finalize, зачем нужно воротить?

Финалайзер это совсем другое.

... << RSDN@Home 1.1.4 beta 1 >>

Здравствуйте, Serginio1, Вы писали:

S>>> Изучи исходники Delphi и сразу все станет ясно, зачем нужны виртуальные конструкторы, класс виртуальные методы итд.
kuj>>Нет, спасибо. Изучать исходники Делфи не входит в сферу моих интересов и обязаностей. Разве что, как пример неудачной архитектуры.
S> Да уж такое высказывание говорит о многм.
Борланд это тоже осознала.
S>И зачем это позвольте Вас спросить M$ переманила к себе Андреаса Хейлсберга,
На ошибках учатся. Не привлекать же им архитекторов MFC.

S>после которой потянулись суды и в итоге M$ скупила 10% акций Борланда, заключило патентное соглашение в итоге выплатив порядка 100 миллионов $. Не плохая цена за неудачную архитектуру.
А при чем тут архитектура? Архитектура VCL, к счастью, осталась в прошлом.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Gregory_krovosos, Вы писали:

G_>Ну если элементов не много, то да.

Много понятие относительное. Скажем так пока памяти хватает и можно построить хороший хэш-то хэш-таблица лучший выбор.

G_>Ну понятно, что можно написать все что угодно

Речь идет о простом решении.

Написать простой класс — это сложное решение?

G_>Ну я с шарпом только начал разбираться, но думаю что ты прав в чем-то. Обычно в деструкторе чистят мусор, а здесь это делается автоматически.

Скажем так. На С++ (где деструкторы в ходу) в них обычно чистятся не какие-то ресурсы ОС, а банально память освобождается. И все это нужно прописывать. По жизни если приспособить классы использующие ресурсы ОС к стилю "как можно позже занял, как можно раньше отдал", то все становится довольно просто. А память... "память больеш не ресурс." (с) ИТ

И получается, что с тебе снимается еще одна почетная обязанность и ты можешь посвятить болше времени вторчесту. В общем, чистота языка того стоит. Хотя конечно возможно можно было бы найти и более красивое решение.

G_>Я с 4-кой не работал, начал с 1-ой версии дельфи

и потом перепрыгнул сразу на 5-ю

VCL конечно не идеал, но в целом более менее.

А вот мы начали со 2-ой и мучились до 4-той.

G_>Глюков (явных) заметил всего несколько штук, при этом они исправляются.

Ну, ждать от моря погоды было некогда.

G_>PS Не в тему — как шарп относится к ресурсам? В смысле работащее приложение много жрет?

Памяти? Памяти оносительно много. По крайней мере больше чем С++ и Дельфи. Но на современных объемах более чем приемлемо. К тому же ЖЦ (отвественное за пожирание памяти) — это такой алгоритм, что он будет работать быстрее на большем общеме за счет пожирания памяти, и не будет жрать памтяи если ее мало, но естественно будет работать медленнее.

Остальные же ресурсы как любой другой компилятор. Ну, еще грузятся приложения несколько медленнее.

... << RSDN@Home 1.1.3 beta 2 >>

	От:	sergei74ap
	Дата:	01.08.02 13:42
	Оценка:

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	01.08.02 13:45
Оценка:	1 (1) +2 -1

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	01.08.02 13:51
Оценка:	3 (1) +2

	От:	achp
	Дата:	01.08.02 13:54
	Оценка:	+1 -2

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	01.08.02 14:05
Оценка:

От:	Young	yunoshev.ru
Дата:	01.08.02 14:20
Оценка:	-2

От:	Хитрик Денис	RSDN
Дата:	01.08.02 14:33
Оценка:	+1

От:	Anatolix	https://www.linkedin.com/in/anatolix/
Дата:	01.08.02 14:58
Оценка:

	От:	Dr_Sh0ck
	Дата:	01.08.02 16:01
	Оценка:	82 (10) +2 -1

От:	Aquary	https://wmspanel.com/
Дата:	02.08.02 00:47
Оценка:

	От:	Igor Trofimov
	Дата:	02.08.02 06:13
	Оценка:	26 (5) +1

От:	epflorov	www.epflorov.hotbox.ru
Дата:	02.08.02 09:22
Оценка:	3 (1)

От:	IT	linq2db.com
Дата:	02.08.02 13:39
Оценка:	21 (3)

	От:	Eugene_B
	Дата:	02.08.02 17:15
	Оценка:	28 (5) -1

	От:	AlexandrShch
	Дата:	03.08.02 08:31
	Оценка:	22 (3)

От:	CooLer	http://bestsoft.far.ru
Дата:	05.08.02 12:06
Оценка:	9 (2)

От:	econt	http://cprime.110mb.com
Дата:	07.08.02 07:51
Оценка:

От:	Aquila	http://www.wasm.ru
Дата:	07.08.02 08:06
Оценка:

От:	Ибрагим	http://blogs.rsdn.org/ikemefula
Дата:	08.08.02 09:34
Оценка:

	От:	Frostbitten
	Дата:	08.08.02 10:38
	Оценка:	10 (2)

От:	m.a.g.	http://dottedmag.net/
Дата:	08.08.02 12:32
Оценка:	+1

	От:	Hacker_Delphi
	Дата:	08.08.02 18:18
	Оценка:	-1

	От:	Patalog
	Дата:	09.08.02 07:14
	Оценка:	5 (1) +1

	От:	Steppenwulf
	Дата:	15.09.02 08:56
	Оценка:	6 (1)

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	15.09.02 14:21
Оценка:	28 (2)

От:	Алекс	http://wise-orm.com
Дата:	16.09.02 05:04
Оценка:

От:	comer	http://getboost.codeplex.com/
Дата:	18.09.02 14:16
Оценка:

От:	Whistler	Блог на GotDotNet.ru
Дата:	01.10.02 15:44
Оценка:	-10

	От:	Lonely Dog
	Дата:	02.10.02 13:47
	Оценка:	3 (1)

От:	VladD2	www.nemerle.org
Дата:	02.10.02 20:46
Оценка:	49 (3) +1

От:	Sinclair	https://github.com/evilguest/
Дата:	07.10.02 17:14
Оценка:

От:	DemAS	http://demas.me
Дата:	08.10.02 12:06
Оценка:	3 (1) +1

От:	siberia	http://siberiaway.com
Дата:	20.11.02 07:48
Оценка:	3 (1)

	От:	Anton V. Kolotaev
	Дата:	23.12.02 13:13
	Оценка:

	От:	SergeyB
	Дата:	24.12.02 12:20
	Оценка:	29 (2) +1