Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, hattab, Вы писали: H>>Да, были и есть в ней приблуды для веба, но нужно же понимать, что это не основное ее предназначение. MC>Воо. Дотнету, например, ничто не мешает конкурировать с дельфи (я имею в виду дельфи как платформу: язык дельфи+VCL/CLX+тулзы от борланда) в его нише и при этом иметь не приблуды, а полноценные инструменты для веба.
WebSnap вполне себе полноценный инструмент. IntraWeb аналогично, с той разницей, что захостить IntraWeb удастся скорее всего, либо на дедике, либо на своем железе. Их направленность именно корпоративный сектор. Для простых страничек нужно использовать что нибудь другое.
G>1)Такой объем кода совсем без комментов — моветон G>2)Многовато кода для обычного replace G>3)Нет поддержки Uincode G>4)Разве в стандартных средствах нет такой функции?
1. Этот код будет переложен на ассемблер, если будет не лень
2. Это цена за скорость и аккуратную работу с памятью. Знаете, как в Delphi строки устроены?
3. Бай дизайн. Работаем только с однобайтовыми кодировками. Весь юникод идет в UTF-8
4. Именно такой нет. Есть StringReplace, но для моей задачи он не подходит.
Здравствуйте, hattab, Вы писали:
H>1. Этот код будет переложен на ассемблер, если будет не лень H>2. Это цена за скорость и аккуратную работу с памятью. Знаете, как в Delphi строки устроены? H>3. Бай дизайн. Работаем только с однобайтовыми кодировками. Весь юникод идет в UTF-8 H>4. Именно такой нет. Есть StringReplace, но для моей задачи он не подходит.
Похоже на ЖИРНУЮ точку в этом топике. Все уродство Delphi на лицо... Добавить нечего.
Здравствуйте, hattab, Вы писали: H>>>Да, были и есть в ней приблуды для веба, но нужно же понимать, что это не основное ее предназначение. H>WebSnap вполне себе полноценный инструмент.
Вы уж это... сами определитесь, приблуда это или полноценный инструмент
H>Что объяснять? Почему проблем нет? Так все дело в руках, в чем же еще. Или ты думаешь, что никто кроме тебя DirectX из под Delphi не юзал чтоль? Я тут ссылочку давал на wiki со списком Delphi-софта, даже там есть чего-то на DX. Однозначно это не косяк Delphi (у нее была проблема с кодогенерацией на константных массивах, но к делу явно отношения не имеет).
Так всё-таки может объяснишь тогда хотя бы как надо? Напомню пример:
var pTexture : IDirect3DTextture9;
...
pTexture := nil; //тут будет аксесс виолейшн, если переменная уже nil.
H>Ага Покури чего нибудь на счет OpenGL. Что нибудь близкое к GLScene. Боюсь обкуришься
Именно его и курил по докам. В чём сложность-то?
H>Компоненты должы всегда предоставляться в исходниках. Это первое правило при использовании сторонней либы. Иначе ССЗБ.
В первой функции 30% кода — это приведение типов. Разве это нормально?
H>У меня сегодня круговая оборона, все нормально
Кстати, у меня до сих пор осталась привычка возвращаемую переменную называть Result — привет из прошлого дельфийского опыта Хотя на дельфях уже лет 5 ничего не писал
Здравствуйте, misha_irpen, Вы писали:
_>Постоянно читая RSDN имел возможность неоднократно убедиться что большинство участников сильно не любят Delphi. Уж очень стало интересно, а за что собственно?
Лень все ответы читать, отвечу как думаю сам.
_>Сам я от большого программинга уже отошел, хотя по прежнему могу считать себя профессионалом Delphi и ASM. И у меня приактически никогда не возникало проблем из-за каких-то ограничений языка. Я с уверенностью могу сказать, что могу написать на нем абсолютно все что угодно в рамках имеющихся API и математических моделей. При этом практически никогда не приходится изобретать велосипедов и извращаться чтобы обойти ограничения языка или стандартных библиотек. В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин?
1) Язык. многословный, не всегда последовательный.
2) Сильная типизация. Сама по себе вещь хорошая, но в дельфи это такая вещь в себе. когда начинаешь юзать сторонние апи, она летит к черту.
3) Для какого то нового апи или библиотеки надо писать обертки/декларации, или искать, может уже кем-то написано. Для С/С++ это обычно в комплекте идет.
4) Наличие компонентов "на все случаи жизни". Шаг влево, шаг вправо == попытка к бегству, расстрел. гемор, если начинаешь делать что-то отличающееся.
5) Программисты дельфи. это самое мрачное. был грешок, работал долгое время на поддержке дельфевых прилад. начальнег (мегакрутой спец по дельфи и прикладной области), как то с трепетом мне показал единственный! юнит, который он сделал, оформив его для повторного использования. в юните была одна функция, разбивавшая строку по табам вроде. в коде этой функции раз пять в разных местах было сравнение с явно прописанной константой символа таб. на мое замечание, почему бы это значение не вынести в аргументы и получить более универсальную функцию, этот чел сказал — хм, интересная мысль.
Ну а так — язык как язык, есть своя ниша. Но я лично цпп предпочитаю.
_>Во время пика своей популярности Delphi занимал ту нишу, которыю ныне занимают управляемые языки программирования. Выходит что позиционирование у него верное, неужели всм оказалась так нужна эта управляемость кода? Кстати, сборка мусора для некоторых типов данных (строки и динамические массивы) у Delphi была уже тогда.
Язык кривой. Сборки мусора не было у строк. просто автоматически память выделялась под паскаль строки длинной до 255 символов. это как если бы говорить, что у std::string есть сборка мусора. Массивы, я так понимаю, подразумеваются не динамические, а автоматические.
_>Или может вам не нравиься Pascal? Но из других ваших сообщений явно следует что синтаксис -- это вторичное, да и наездов на него я вроде как не видел...
Не нравится. какашка язык.
_>Просветите плиз вашу точку зрения, только объективно. Сетования на многомилионную армию малограмотных формоклепальщиков не принимаются, это не есть свойство языка или среды разработки.
есть. свойство. языка. и среды. моск атрофируется. на билдере тоже формошлепщики есть, хотя таких меньше. потому что с дельфей никто не пересаживается — язык сложнее, и формы клепать труднее. кому это надо.
дельфи — в основном формошлепство, в этом ему нет конкурентов. и это без насмешек, это действительно очень удобно там. в билдере уже не так все просто. ничего другого, такого же удобного для клепания форм не видел. хотя в этом плане не старался развиватся и мог что-то пропустить.
самое печальное — знания дельфи, языка, компонент имхо не нужно особо. никаких фундаментальных идей там не найдешь, ничему новому не научишся. будешь ковырятся — только время зря потратишь.
Здравствуйте, misha_irpen, Вы писали:
_>Сам я от большого программинга уже отошел, хотя по прежнему могу считать себя профессионалом Delphi и ASM. И у меня приактически никогда не возникало проблем из-за каких-то ограничений языка. Я с уверенностью могу сказать, что могу написать на нем абсолютно все что угодно в рамках имеющихся API и математических моделей. При этом практически никогда не приходится изобретать велосипедов и извращаться чтобы обойти ограничения языка или стандартных библиотек. В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин?
По поводу выделенного. Си-шарпом вроде занимался тот же перец, который лет пятнадцать назад дизайнил дельфи.
Здравствуйте, Marty, Вы писали:
M>Язык кривой. Сборки мусора не было у строк. просто автоматически память выделялась под паскаль строки длинной до 255 символов. это как если бы говорить, что у std::string есть сборка мусора. Массивы, я так понимаю, подразумеваются не динамические, а автоматические.
Нет, подразумеваются именно динамические массивы и именно сборка мусора.
M>самое печальное — знания дельфи, языка, компонент имхо не нужно особо. никаких фундаментальных идей там не найдешь, ничему новому не научишся. будешь ковырятся — только время зря потратишь.
Применив делфи правильно и вовремя — можно время здорово сэкономить, как раз благодаря скорости формошлепства.
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, Marty, Вы писали:
M>>Язык кривой. Сборки мусора не было у строк. просто автоматически память выделялась под паскаль строки длинной до 255 символов. это как если бы говорить, что у std::string есть сборка мусора. Массивы, я так понимаю, подразумеваются не динамические, а автоматические.
С>Нет, подразумеваются именно динамические массивы и именно сборка мусора.
Напомните как они созданются и используются, а то что-то не могу вспомнить.
M>>самое печальное — знания дельфи, языка, компонент имхо не нужно особо. никаких фундаментальных идей там не найдешь, ничему новому не научишся. будешь ковырятся — только время зря потратишь.
С>Применив делфи правильно и вовремя — можно время здорово сэкономить, как раз благодаря скорости формошлепства.
можно. но это скорее относится к штучно изготавливаемым программам. в серийных обычно имеет смысл потратить время на оттачивание интерфейса
gandjustas пишет: > Еще раз повторяю, все современные языки полны по тьюрингу. > Спорить об этом смысла нет.
Нет, есть. Достаточно вспомнить, что такое эта машина Тьюринга. Число
занимает столько места, сколько оно есть. О производительности никогда
не встаёт вопроса. Вся эта машина Тьюринга — это чисто академические
заморочки. На практике тьюринг–полнота как таковая ещё имеет какой–то
смысл, но уравнивать ею языки не получится.
> То есть то что сделано на одном языке — может быть сделано на другом.
А вот физики говорят, что все поля эквивалентны, и при сверхбольших
энергиях становятся неотличимы (или что они там говорят?). В реальной
жизни это знание очень помогает, я заметил.
Здравствуйте, misha_irpen, Вы писали:
_>Просветите плиз вашу точку зрения, только объективно. Сетования на многомилионную армию малограмотных формоклепальщиков не принимаются, это не есть свойство языка или среды разработки.
Первые 10 страниц я прочитал, дальше уже не могу. Потому извиняюсь если дублирую чей-то другой пост.
Самое первое, что хотел бы заметить — это то, что мы живем в жестоком мире, где главное не качество, а маркетинг и продвижение. Сколько прекрасных технологий не выжило из-за более баблистых конкурентов? А сколько просто не вышло на рынок? А сколько авторов даже не начали работу из-за боязни конкурентов?
Короче все это — cruel world.
Сколько раз MS делала подлянки с частичным выполнением стандарта или недокументированым API? И в результате у конкурентов выходили несовместимые продукты, которые не могли предоставить весь функционал продуктов мс. ессно заказчики просили писать на технологии, которую "рекомендует" мс.
Как удается в таких условиях выжить джаве — мне непонятно, но sun держиться и они молодцы.
Потому уход делфи из рынка я считаю на 60% по маркетинговым причинам, а не техническим.
Теперь техническая часть.
Сразу оговорюсь — я с самых пеленок (в переносном смысле) ориенторовался на продукты MS исходя из простой как сало истины "бабло побеждает зло", но дальшие мысли попытаюсь сделать максимально объективными.
И еще: опыта в разработке на делфи у меня немного, использовал его когда только преподы заставляли писать именно на нем.
1. Делфи в некоторых вещах даже опередило свое время: в частности в datatable/gridview (может называется по-другому, но думаю все поняли). Такого уровня легкость работы с источниками данных и их отображением появилась только в .net 1.1/2.0 (2003/2005). НО при желании сделать "чуть влево-чуть вправо" надо было потратить намного больше усилий, чем сделать "по прямой". Это отталкивало и казалось что решение нерасширяемо (еще раз повторюсь, что это все ИМХО). Очень много механизмов в делфи скрыто от глаз девелопера, а вообще-то прятать надо их от юзера, а не девелопера.
2. Оптимизация. Я начинал писать любой модуль с {$O-}.
Один раз у меня был цикл
for i:=0 to 8 do
...
каково было мое удивление когда он после 8 шел в 9, 10 и так до 12, где вылезала ошибка доступа. Тогда я отнес код преподу, который слегка о*[удивился]*л с таких дел.
И это не единственный случай.
2.1. "Inaccessible due optimization". Кто знает, тот поймет.
3. IDE. Это самое слабое место всей цепочки.
3.1. Ошибка работы с чем-то.
Наверное все попадали в ситуацию когда Delphi IDE нарывалось на какую-то ошибку. Тогда оно начинало об этом гласить через какое-нить окно с единственной кнопкой "OK", часто еще с паузой в 2-3 с, с зависанием среды и в цикле. Например если что-то случилось с БД или компонент не найден.
3.2. Intellisense (ну или как там его) — мелочь, но неприятно.
Не прикалывало то что подсветка фильтрует следующий идентификатор согласно типа. Т.е., если я хочу написать
iSomeVal := getString().Length;
то метод getString() не высветится, т.к. он возвращает string а не integer.
3.3. Совсем мелочь, но задолбало. Удаление пустых обработчиков.
Лично я (потеряв из-за сбоев не один кусок кода) нажимаю Ctrl+S через каждые 5-10 с. А делфи "оптимизирует" код и удаляет пустые обработчики (в т.ч. и новосозданные). А еще когда не находит какой-то контрол норовит удалить его с формы. Такое впечатление, что из формы можно удалить контрол и все будет ОК — прога запашет. Типа девелоперы могут просто так кидать контролы.
4. "Закон один для всех". В делфи часто встречаются исключения. Например writeln — чуть ли не единственная функция, куда можно передать переменное к-во параметров. А вот простым смертным — низза. Похожая ситуация с массивами.
Остальные замечания еще меньше, потому даже писать не буду.
Резюме
Спрос на любую технологию формируется с двух сторон:
1. Заказчик.
1.1. Есть уже готовач инфраструктура на некой технологии. Отсюда некоторая инертность рынка.
1.2. Есть удачный опыт работы с технологией.
1.3. Просто скзали/услышая, что эта технология — круто.
2. Программист.
2.1. Опыт работы с технологией.
2.2. Удобство.
2.3. Библиотеки.
и т.д.
именно п.2. формируется из этих многих ИМХО которые перечислены в этой ветке (сила мелочей в том, что их много). Каждая мелочь (приятная и не очень) формирует ИМХО, которое потом формирует ИМХО коллективное, а в последствии — рынок. А еще на ИМХО влияет реклама и усилия по продвижению.
Вывод
Задача IT — предоставление сервисов в других областях народного хозяйства. Потому если вы можете сделать своего заказчика счастливым на delphi — делайте, ему скорее всего абсолютно пофиг что вы используете. Коллективное ИМХО отодвинуло delphi на второй план, но это абсолютно никому не мешает использовать его в своем проекте — главное чтобы закачик был счастлив.
If the message above is in English — means I'm wasting my work time and work computer to post here. No hard feelings
machine3000 пишет: > Также C++ даёт возможность размещать классы не только в куче, но и в > стеке и в глобальной памяти.
В C++ нельзя возвращать из функции объекты размера, не известного на
этапе компиляции.
а) строки
б) экземпляры потомка класса
C++ позволяет часть вещей сместить на стек, но не до конца. В этих
случаях будет динамическая память. IIRC в C++ нельзя конструировать
результат прямо на месте.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>C++ позволяет часть вещей сместить на стек, но не до конца. В этих OCT>случаях будет динамическая память. IIRC в C++ нельзя конструировать OCT>результат прямо на месте.
То есть?
Существует in-place new и RVO (return value optimization). В следующем Стандарте RVO станет более мощной из-за move constructors.
gandjustas пишет: > Я больше всего работал в Delphi7 — большенитсво впечатлений оттуда.
Delphi7 — это 2001й год. С тем же успехом можно ругать Windows за
дырявость, а IE — за отсутствие табов.
hattab пишет: > Vendor.App.Lib1.Class1? Это есть.
Delphi 2007?
>> > OCT>автоматическая финализация; >> > >> > Есть, для управляемых типов. > OCT>Самые обычные объекты — управляемые? > > Нет конечно Advanced records (class-like) финалятся
тоже 2007? в 2006 не помню такого
> Чем это будет отличаться от: > > Var > Buffer : Array Of ...; > > Begin > > SetLength(Buffer, NeededLength(...));
Быстродействием.
Здравствуйте, Niemand, Вы писали:
N>Один раз у меня был цикл N>
N>for i:=0 to 8 do
N>...
N>
N>каково было мое удивление когда он после 8 шел в 9, 10 и так до 12, где вылезала ошибка доступа. Тогда я отнес код преподу, который слегка о*[удивился]*л с таких дел.
Скорее всего хреновый был препод. Тема с оператором for постоянно всплывает в разных форумах по Delphi, проблема в том что отладчик неправильно показывает значение счётчика цикла for (если бы он его вообще не показывал, было бы меньше вопросов). На практике это часто выглядит так: пишется for-цикл с неочевидной ошибкой, начинают его отлаживать и обнаруживают, что ошибка проявляется когда счётчик цикла находится вне допустимого диапазона. Самое интересное начинается, если эта ошибка исчезает при отключении оптимизации или при замене for на while (и такое бывает ). У меня самого однажды было такое, для поиска ошибки пришлось неспешно изучать ассемблерный код в отладчике, и в результате for был оправдан.
---
The optimist proclaims that we live in the best of all possible worlds; and the pessimist fears this is true
Здравствуйте, goto, Вы писали:
G>В той конторе, где начинал я, мэйнфреймы и т. наз. мини-эвм, жили подольше. Парк был очень разнообразным. Собирались еще ставить Эльбрус. Да, формально отмечу, что забыл про относительно стандартный PL/1, приходилось его использовать для переносимости из-за личной нелюбви к Фортрану 4.
А можно подробнее о переносимости? У нас как раз код на Фортране работал примерно на 6-7 разных платформах без переделки. И, если не ошибаюсь, работал быстрее PL/1. А в условиях дороговизны машинного времени с этим тоже нужно было считаться.
Здравствуйте, kuj, Вы писали:
H>>1. Этот код будет переложен на ассемблер, если будет не лень H>>2. Это цена за скорость и аккуратную работу с памятью. Знаете, как в Delphi строки устроены? H>>3. Бай дизайн. Работаем только с однобайтовыми кодировками. Весь юникод идет в UTF-8 H>>4. Именно такой нет. Есть StringReplace, но для моей задачи он не подходит.
kuj>Похоже на ЖИРНУЮ точку в этом топике. Все уродство Delphi на лицо... Добавить нечего.
Я уже привык вести тут неконструктивные споры. Ты про фризы давай растолкуй.
Здравствуйте, Mr.Cat, Вы писали:
H>>>>Да, были и есть в ней приблуды для веба, но нужно же понимать, что это не основное ее предназначение. H>>WebSnap вполне себе полноценный инструмент.
MC>Вы уж это... сами определитесь, приблуда это или полноценный инструмент
Ну вообще, для Delphi, это приблуда, ибо нифига не основную задачу решает на которую Delphi точилась. А так вообще инструмент, как инструмент...
Здравствуйте, koandrew, Вы писали:
H>>Что объяснять? Почему проблем нет? Так все дело в руках, в чем же еще. Или ты думаешь, что никто кроме тебя DirectX из под Delphi не юзал чтоль? Я тут ссылочку давал на wiki со списком Delphi-софта, даже там есть чего-то на DX. Однозначно это не косяк Delphi (у нее была проблема с кодогенерацией на константных массивах, но к делу явно отношения не имеет).
K>Так всё-таки может объяснишь тогда хотя бы как надо? Напомню пример: K>
K>var pTexture : IDirect3DTextture9;
K>...
K>pTexture := nil; //тут будет аксесс виолейшн, если переменная уже nil.
K>
К ошибкам такая конструкция приводить не должна. Если приводит, дело в коде. Еще может быть косяк с неправильным использованием интерфейсной переменной переданной в качестве константного параметра.
H>>Ага Покури чего нибудь на счет OpenGL. Что нибудь близкое к GLScene. Боюсь обкуришься
K>Именно его и курил по докам. В чём сложность-то?
До уровня GLScene. Сложность в том, что никакое готовое API тебе такого (как GLScene) высокого уровня не даст.
H>>Компоненты должы всегда предоставляться в исходниках. Это первое правило при использовании сторонней либы. Иначе ССЗБ.
K>А если всё-таки нужный мне компонент поставляется только в двоичном виде? Что делать?
Вполне. Мне так нравится. Можно было переписать с использованием типизированных указателей, но зачем? Я уже писал, что эта функция кандидат на полное переписывание на асме. Могу дать еще один пример с указателями:
//Procedure XmlRpcVarDispInvoke(Dest : PVariant; Const Source : Variant; CallDesc : PCallDesc; Params : Pointer); Cdecl;
Const
atTypeMask = $7F;
atByRef = $80;
Var
PIndex : Integer;
Strings : Array Of WideString;
StrLen : Integer;
ArgPtr : Pointer;
ArgType : Integer;
ArgByRef : Boolean;
//Procedure _IncArgPtr;
Begin{$REGION ' Контроль размера типов '}
{$IF SizeOf(Pointer) <> 4}
{$MESSAGE FATAL 'Проверить алгоритм расчета смещений (см. ComObj.DispatchInvoke)'}
{$IFEND}
{$ENDREGION}If ArgType <> varError Then
Begin
If Not ArgByRef Then
Case ArgType Of//
varVariant :
If PVarData(ArgPtr)^.VType <> varString Then
Inc(Cardinal(ArgPtr), SizeOf(TVarData) - SizeOf(Pointer));
//
//
varDouble .. varDate, varInt64 :
Inc(Cardinal(ArgPtr), 8 - SizeOf(Pointer));
//End;
Inc(Cardinal(ArgPtr), SizeOf(Pointer));
End;
End;
//Begin// Если кодирование юникода не блокировано и происходит вызов метода...If (EncodingLocks = 0) And (CallDesc.CallType = DISPATCH_METHOD) Then
Begin
StrLen := 0;
ArgPtr := Params;
// Перебираем все параметры...For PIndex := 0 To CallDesc.ArgCount - 1 Do
Begin// Получаем тип параметра и способ его передачи
ArgType := CallDesc.ArgTypes[PIndex] And atTypeMask;
ArgByRef := CallDesc.ArgTypes[PIndex] And atByRef <> 0;
//
// Если параметр является юникод-строкой...If ArgType = varOleStr Then
Begin// Увеличиваем размер массива перекодированных строк
SetLength(Strings, StrLen + 1);
// Если параметр передается по ссылке...If ArgByRef Then
Begin// Перекодируем строку и обновляем ссылку в параметре
Strings[StrLen] := Utf8Encode(PWideString(ArgPtr^)^);
Pointer(ArgPtr^) := Pointer(@Strings[StrLen])
End
Else// ... по значению...Begin// Перекодируем строку и обновляем ссылку в параметре
Strings[StrLen] := Utf8Encode(PWideString(ArgPtr)^);
Pointer(ArgPtr^) := Pointer(Strings[StrLen]);
End;
// Увеличиваем счетчик перекодированных строк
Inc(StrLen);
End;
// Считаем смещение следующего параметра
_IncArgPtr;
End;
End;
// Вызываем старую процедуру диспетчеризации вызова
OldVarDispProc(Dest, Source, CallDesc, Params);
End;
//
