Здравствуйте 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 был упомянут как раз в качестве недостатка Паскаля

А>С другой стороны, многим приложениям не нужны строки в стиле Си, а если и нужны, то БП и ОП (но не виртов Паскаль) это дело тоже поддерживают.

Ага-ага!

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

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

Поскольку это форум по философии то позволю себе немного по философствовать:

Представим себе 2 поваров. Один из них пусть будет англичанином, второй французом. Пусть они оба готовят курицу. (Че-то есть захотелось )
У одного рецепт этого блюда на английском , и у второго на французком. Как вы думаете, у кого курица получится вкуснее?

PS: Мне кажется, что споры про среды программирования сродни спору про курицу.

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

LD>Представим себе 2 поваров. Один из них пусть будет англичанином, второй французом. Пусть они оба готовят курицу. (Че-то есть захотелось )
LD>У одного рецепт этого блюда на английском , и у второго на французком. Как вы думаете, у кого курица получится вкуснее?

LD>PS: Мне кажется, что споры про среды программирования сродни спору про курицу.

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

Здравствуйте 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>Чего на мои письма не отвечаешь, ******* фигов? Что слабо на моих условиях соревноваться? Давай сравнивать, если хочешь я условия повторю, могу прям здесь. Судя по тону я так понимаю ты на любые условия согласен. Может хоть после этого поймешь, что такое Delphi и где его место. Причем место совсем не позорное и мной уважаемое, но есть целый класс задач в которых он ***** и ****** будет во веки вечные у ненавистного тебе VC++. Взяли манеру над сишниками издеваться глядя на обиженных BC++'ев.

Я вижу ты тоже в банлист захотел? Могу устроить.

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

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

Автор: VladD2
Дата: 31.07.01

.

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

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

Ну гляди здесь. Все наши программисты от трех до семи лет отработали на паскале. Кода было решено делать компоненты, пересели на 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.

Это ты так прикалываешся?