Delphi мертвый язык?

Сам работаю с oracle, недавно обнаружил, что такие известные функциональные программы как PLSQL Developer, Toad и SQL Navigator сделаны на Delphi.

Кроме того почти у каждого стоит, что-то из этого популярного ПО:
— Total Commander
— The KMPlayer
— Light Alloy
— QIP
— Download Master
— The Bat!
— FastStone Image Viewer
— FastStone Capture
— Парус Бухгалтерия
которое написано на Delphi.

Почему же тогда говорят, что этот язык отмирает?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Варт Дейдер 8 мин. назад
Народ, а как думаете, эти олухи свою поделку тоже на делфе делали?

friendlyseats.com

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

Жалко ведь людей.


eugene_n 6 мин. назад
>> Типа торент-клиента, визуального Ftp-сервера (Serv-U), LDAP-администратора или же комфортного чат-клиента (Skype, ComfortChat-к приммеру).

Это типо внутренние проекты?

Не знаю, они уже на Delphi.

Ото вам нечего делать. Делфи жив, пока будут живы такие топики. Хоть и пахнет.

Типа торент-клиента, визуального Ftp-сервера (Serv-U), LDAP-администратора или же комфортного чат-клиента (Skype, ComfortChat-к приммеру).

Это типо внутренние проекты?


eugene_n 1 мин. назад
Мелкие и неответсвенные утилиты, типа учета рабочего времени и автоматизации повседневной работы.
Типа торент-клиента, визуального Ftp-сервера (Serv-U), LDAP-администратора или же комфортного чат-клиента (Skype, ComfortChat-к приммеру).
Ну, а веб-решения? Делфи туда особо не лезет. Есть конечно пародия DelphiPHP, но вменяемый человек её использовать не будет.
Добавил:
Все что десктоп, с малым системным сопровождением (большинство ПО под десктоп) и под Windows, там Delphi выигрывает по всем параметрам.
Нативное приложение, довольно скромного размера (средний размер ПО на Delphi ~3Mb), со скорость работы с бинарными данными чуть медленнее С, а со строковыми чуть быстрее C#/Java.
Гейм-девелопмент, хто и возможен на Delphi (есть хидеры для DirectX7−11, и враппер над Lua), но традиционно скорость чуть выше на С/С++

Веб — мелочь на php, крупное на Java, еще Asp.Net очень хвалят (но никогда не работал).

Смотря что понимать под внутренним.

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


eugene_n 3 мин. назад

Ключевое слово. Здесь Делфя безусловный лидер...

Смотря что понимать под внутренним. Если предприятие не устраивает 1С, то можно нанять программиста который за год на готовом фреймворке напишет ПО для внутреннего использования (в том числе и web) под бизнес-процесс, а не погнёт бизнес-процесс под ПО. А суммарная прибыль от этого может измерятся в сотнях тысяч долларов.

программки для внутреннего использования,

Ключевое слово. Здесь Делфя безусловный лидер...


Варт Дейдер 8 мин. назад
Народ, а как думаете, эти олухи свою поделку тоже на делфе делали?

friendlyseats.com

Можно и на Delphi, виртуальные десктопы можно создавать начиная от Win2000. Просто оно никому не нужно, так как проще поставить RDP терминал за 100$ к которому и подключать всё.

Народ, а как думаете, эти олухи свою поделку тоже на делфе делали?
friendlyseats.com
Кстати о сабже есть интересный форум

netadmin.org.ua/...m/viewforum.php f=6

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

Если смотреть по максимальным зарплатам, то разницы между Java и Delphi почти нет.

Смотреть по максимально возможному глупая затея, по ряду причин. Но если все таки глянуть, то:
Java 27 анкет 3000 2000 4000
Delphi 19 анкет 2000 960 2539

Кстати, со всей Украиной такая же история, как и с ЗП в Киеве.

Все проще. Он — живой пример фразы «Вася в танке».


qwerty_smerty 5 час. назад
На дворников тоже спрос есть, или кто нибудь сомневается в их полезности? Средняя зарплата дельфина 1250 баксов, жабиста — 1837 Имхо, разница что называется на лице. Ещё раз, делфи это в основном допиливание старых проектов
Если смотреть по максимальным зарплатам, то разницы между Java и Delphi почти нет. А минимальный вход всё таки проще в Delphi так как Delphi для дескткопа это как php для веба. Так что мышкой писать ПО на Java все таки довольно сложно, а на Delphi возможно.

Хотя джуны в Delphi почти уже не требуются, а для сеньеров работу найти не так уж и сложно.

изучать нефиг, самим мало. Но спрос есть.

На дворников тоже спрос есть, или кто нибудь сомневается в их полезности? Средняя зарплата дельфина 1250 баксов, жабиста — 1837 Имхо, разница что называется на лице. Ещё раз, делфи это в основном допиливание старых проектов.


И поскольку уточнение определения давалось чайником, вместо определения танка мы получили САУ.
76.2 мм это «крупнокалиберное пушечное»? А 45 мм? А 37 мм? А, как Вы думаете, пулемётных танков не бывает?

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

Да, я ламер в бронетехнике, как и ты в программировании.


qwerty_smerty 59 мин. назад
Заходим сюда — же на девелоперс, в раздел вакансии. Смотрим на количество оных по.NET, Java, Flex сравниваем с количеством по Delphi.

Потом сравниваем зарплаты и делаем вывод о целесообразности изучения делфи

В общем-то да
Delphi — 33 вакансии
www.rabotaplus.com.ua/...vacancy/search type=vacancy& search=delphi& city=& cat_id=53& sort=20
C# — 159

Так что изучать нефиг, самим мало. Но спрос есть.

Ребята, о чем вы спорите?
Заходим сюда — же на девелоперс, в раздел вакансии. Смотрим на количество оных по.NET, Java, Flex сравниваем с количеством по Delphi.

Потом сравниваем зарплаты и делаем вывод о целесообразности изучения делфи


А казалось бы — добавь к определению фразу: «оснащенная крупнокалиберным пушечным вооружением в качестве основного», и вопросов бы стало значительно меньше.
И поскольку уточнение определения давалось чайником, вместо определения танка мы получили САУ.
76.2 мм это «крупнокалиберное пушечное»? А 45 мм? А 37 мм? А, как Вы думаете, пулемётных танков не бывает?

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

2 Паря

Мир приблизился к хаосу, когда быдлокодеры бросили Делфи и перешли на пых-пых

С меня потребовали пример, где бы наследования не было бы буквально. Я привёл.

Ты убрал наследование используя особенности языка (динамическая типизация, reflection), на С++ бы такое не прокатило очевидно.

Вот, например, классическое определение: «Танк — боевая гусеничная машина, сочетающая в себе такие основные свойства как огневая мощь, защита и подвижность.» Профессионалов оно никогда не смущало и не смущает, ламеры постоянно недоумевают почему оно такое «кривое», ведь под него можно подвести и БМП, и гусеничные БТР, и САУ и др. технику.

А казалось бы — добавь к определению фразу: «оснащенная крупнокалиберным пушечным вооружением в качестве основного», и вопросов бы стало значительно меньше.

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

Идет себе проэкт, программисты программируют, заказчики выдумывают новые фичи каждый день, менеджмент пресует по срокам, вобщем все как обычно.
Тут приходит он — Архитектор, говорит что все быдлокодеры, и они не используют инкапсуляцию в широком смысле, и у них узок ум для этого. Начинаются долгие терки, что такое инкапсуляция в широком смысле, как все перестроить что бы ее использовать, все ломают и переделывают по 10 раз, потому что Архитектор со стороны своего танкового образования, не приемлет компромисов, и ненавидит быдло кодеров, и не любит консенсусы, программисты начинают программировать не только по ночам и выходным, но и по ночам выходных. В конце концов Архитектор замылив уши уровнем своей мегаквалификации уходит в другую контору, на большую зарплату, программисты и менеджер тоже разбегаются не выдержав графика, проэкт загибается, но процветает в резюме архитектора в виде: перестроил архитектуру системы используя современные подходы OOA, OOD, OOP, OO*, введ 11 слоев абстракции с помощью инкапсуляции в широком смысле, отказавшись от наследования в небуквальном смысле.
Мир еще на шаг приблизился к хаосу.

Занавес.

Василий Чобиток, а у вас есть IT-образование и связанный не с интерфейсами опыт написания программ?

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

Видите ли, Аноним, оппоненту не интересна суть сказанного, он тупо привязался к буквальной интерпретации слов, подходя к разговорному языку с позиций булевой логики. С меня потребовали пример, где бы наследования не было бы буквально. Я привёл. На самом деле этот факт меня не радует и не огорчает, просто хотели получить буквальное соответствие — получите.
Опять же, когда в обратную сторону, буквально следуя семантике шаблона, меня упрекают в несоответствии конкретного решения шаблону... О чём тут тогда спорить? Почему люди, сами назвавшие себя быдлокодерами, начинают обижаться? Если у них отсутствует абстрактное мышление и способность к аналогии, то тут реальная проблема, это профнепригодность.
Для не самых простых понятий краткие определения в большинстве случаев неполны и неоднозначны. В краткое определение трудно вложить всю полноту ширины глубин...
Вот, например, классическое определение: «Танк — боевая гусеничная машина, сочетающая в себе такие основные свойства как огневая мощь, защита и подвижность.» Профессионалов оно никогда не смущало и не смущает, ламеры постоянно недоумевают почему оно такое «кривое», ведь под него можно подвести и БМП, и гусеничные БТР, и САУ и др. технику.

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

2 junior_dev
Он называет уровни абстракции «инкапсуляцией на уровне ООД и ООА» (на уровне ООП — это для него обычное сокрытие реализации класса, как и для всех)
2 Василий Чобиток

Абстрактный класс или интерфейс, или совсем ничего — неважно, главное что пользователь этого «неважно» для вызова стратегии использует одинаковую сигнатуру метода. Как вижу средства ПХП позволяют вызывать метод задавая имя класса на ходу (с ПХП не знаком и это мои догадки), ну что же, хорошо. Это все равно, что в.NET я буду вызывать метод неопределенного класса путем Reflection. И я прицепился к вашей фразе, что «наследование не нужно, но это и не важно». Хоть наследуетесь, хоть нет, у вас все классы алгоритма распределения напрямую зависят от класса-пользователя алгоритма distribution. Все они должны содержать метод distribut. А вы так радуетесь, что там нет наследования (только потому что ПХП), хоть все эти классы алгоритмов без наследования все равно обязаны содержать одинаковый метод. И это смешно.

2Василий Чобиток — может не стоит так часто называть людей вокруг быдло...кем угодно там, и стоит не много уважать если они приводят замечания к вашей модели?

если народ не понимает, может же быть причина и в примере?

Но это неверно. А верно — завести абстрактный класс TTextFilter, про который знает TDocument и методы которого будет использовать. TTextFilter отвечает за чтение и запись текста в поток в соответствующем формате. TdocFilter, ThtmlFilter и т.д. — его наследники, но TDocument о них не знает, это и есть инкапсуляция.

Вы в вашем примере говорите что инкапсуляция это когда класс A использует абстрактный интерфейс I не зная о дереве иерархии под ним...

А верно — завести абстрактный класс TTextFilter, про который знает TDocument и методы которого будет использовать...- его наследники, но TDocument о них не знает, это и есть инкапсуляция

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

Grady Booch defined encapsulation as «the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation.»

Но странно другое, и видимо это и удивило народ

А множественное наследование прекрасно заменяется инкапсуляцией вместо неоднозначностей.
Золотые слова!

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

Может вы путали агрегацию? когда класс A становиться частью класса B, если нет, то в чем действительно разница между наследованием и инкапсуляцией? и как одно может заменить другое?:) ведь вы в вашем примере тож порадили наследование

его наследники, но

при этом говоря что инкапсуляция его может заменить:) ведь рано или поздно вам прийдеться создать конкретного наследника для интерфеса

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

2 Паря:, а Вы похоже не только тролль, но и дeбил. Спасибо за «дискуссию».

Как обычно логика и аргументация зашкаливает. У меня кстати как раз бисер закончился. До свидания.

2 Паря:, а Вы похоже не только тролль, но и дeбил. Спасибо за «дискуссию».

А ничего, что паттерн стратегия предполагает абстрактный класс

Скажите, а если бы вместо абстрактного класса я использовал интерфейс, это тоже не соответствовало бы шаблону Стратегия?; -))
Знаете чем отличаются быдлокодеры? Для них семантика важнее сути.
Шаблоны проектирования показывают идею, идею решения определенной проблемы на уровне проектирования. Используется наиболее удобная объектно-ориентированная семантика. Вы думаете, что в этом случае шаблоны проектирования неприменимы при реализации на процедурном языке? Применимы, т.к. Программист (а не быдлокодер) способен вникнуть в суть, понять идею и реализовать идею в рамках той семантики, которыю предоставляет ему конкретный инструмент.
Вернемся к примеру на PHP. Введу я абстрактный класс «алгоритм», а конкретные алгоритмы унаследую от него, чтобы буквально соответствовать описанию шаблона Стратегия. Как изменится проектное решение? Никак! Идея та же? Та же. У меня совершенно то же самое решение, только примененное с умом, а не быдлокодерски. Вы хотите буквального повторения с наследованием от абстрактного класса? Он от Вас инкапсулирован:) Абстрагируйтесь, вообразите, что он виртуально присутствует. Не воображается? Смените профессию нна...

P.S. Меня всегда раздражало, когда в те же статьи о шаблонах проектирования в Википедии быдлокодеры радостно впихивали обширные примеры кода на языках. Программист должен быть способен понимать идею, вникнуть в суть, а реализация — дело техники.

в примере с распределением судебных дел даже наследования нет, но это не важно!!!

Цитата с сайта:

Для обеспечения возможности подключать другие алгоритмы первый алгоритм serial инкапсулирован (используем шаблон проектирования Strategy)

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

Вы кого за нос водите? Может стоит почитать еще что-нибудь кроме Шаллоуея?

Инкапсулировано может быть «где-то». Нельзя инкапсулировать «от чего-то». Если вы хотите написать просто «сокрыто», так и пишите. А то применяете его в совершенно левом контексте. Нельзя ведь сказать «десантник подбежал к западной части дома и инкапсулировался в кустах»? Или вы употребляете этот термин в целях повышения значимости фразы?

+1

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

Инкапсулировано может быть «где-то». Нельзя инкапсулировать «от чего-то». Если вы хотите написать просто «сокрыто», так и пишите. А то применяете его в совершенно левом контексте. Нельзя ведь сказать «десантник подбежал к западной части дома и инкапсулировался в кустах»? Или вы употребляете этот термин в целях повышения значимости фразы?

1) Сутки назад я приводил цитату из книги «Шаллоуей, Алан, Тротт, Джейм, Р. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию: Пер. с англ. —М.: Издательский дом „Вильямс“, 2002.» Найдите и прочтите, это более чем достаточное объяснение.

Ок, согласен, этот твой коммент я продолбал.

2) Кроме модификации примера про TDocument, я приводил ссылку на другой пример, в котором инкапсуляция на уровне проектирования, а не средствами языка.

Я просил короткий локаничный пример, выискивать здравую мысль в куче говна мне недосуг, извини.

В моем примере изменчивая часть (разные форматы хранения) «вынесена за скобки» и инкапсулирована (скрыта, Вы же согласились, что инкапсуляция — сокрытие) от основного класса TDocument. Мы устранили наследование «основной системы», добавление новых форматов не затрагивает своими изменениями TDocument, а есть там наследники или нет TDocument не знает, от него инкасулировано (в примере с распределением судебных дел даже наследования нет, но это не важно!!!).

В примере когда у TDocument есть наследники, TDocument о них тоже ничего не знает. Так что инкапсуляция есть в обоих случаях, как и ерархия наследования: иерархия наслендиков от TDocument и иерархия наследования TTextFilter (выбор имени класcа похоже свидетельствует о необратимых психических растройствах у автора).

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

Хамливое бла-бла-бла как всегда списываю на старческий климакс.


Перечитывая твои посты я нашел, одно место, которое можно принять за обьяснение понятия инкапсуляции:
1) Сутки назад я приводил цитату из книги «Шаллоуей, Алан, Тротт, Джейм, Р. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию: Пер. с англ. —М.: Издательский дом „Вильямс“, 2002.» Найдите и прочтите, это более чем достаточное объяснение.
2) Кроме модификации примера про TDocument, я приводил ссылку на другой пример, в котором инкапсуляция на уровне проектирования, а не средствами языка. На уровне проектирования пример полностью аналогичен примеру с документом, но вообще без наследования (хотя, это не является самоцелью).

Вас собственные нахально оформленные вопросы интересуют больше, чем терпеливые ответы на них? Почему не читаете?

Возвращаясь к твоему примеру, то от него требовалось показать как наследование заменяется инкапсуляцией. В твоем примере одна иерархия наследования с инкапсуляцией, заменяется на другую с инкапсуляцией. Как бы очевидно что пример неудачен.
Ну, значит, как говорят, не в коня корм и нужных книг Вы в детстве не читали. В моем примере изменчивая часть (разные форматы хранения) «вынесена за скобки» и инкапсулирована (скрыта, Вы же согласились, что инкапсуляция — сокрытие) от основного класса TDocument. Мы устранили наследование «основной системы», добавление новых форматов не затрагивает своими изменениями TDocument, а есть там наследники или нет TDocument не знает, от него инкасулировано (в примере с распределением судебных дел даже наследования нет, но это не важно!!!).

Перестаньте демонстрировать воинствующее невежество и почитайте полезную литературу.


Инкапсуляция — сокрытие

Ок, согласен, это одно из двух определений понятия инкапсуляции распространенных в литературе.

Сутки назад я объяснил, в том числе с цитатой.

Перечитывая твои посты я нашел, одно место, которое можно принять за обьяснение понятия инкапсуляции:

TdocFilter, ThtmlFilter и т.д. — его наследники, но TDocument о них не знает, это и есть инкапсуляция.
Ты это имеешь в виду?

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

Инкапсуляция — сокрытие. Сутки назад я объяснил, в том числе с цитатой. Вам не понятно? Каких ещё объяснений ждете? Как пройти на курсы по ООП для начинающих или на углублённые курсы раскормленных троллей?

Кстати, если хочешь быть конструктивным, а не пустобрехом, все еще жду обьяснения что такое по твоему мнению инкапсуляция.

Простите, но я с Вами на брудершафт не пил.

Это меня к чему то обязывает?

Быдлокодером Вы сами себя идентифицировали: «ты мне ответишь на понятном мне быдлокодерском языке»

Эээ, я где то пропустил, где в этой фразе я себя называл быдлокодером? Проблемы с логикой?

P.S. «Ох уж эти горе-архитекторы...», «Жесть, горе орхетектор-теоретег детектед.» Следили бы за собственным языком, не пришлось бы невинную оскорблённость изображать.

Я по прежнему считаю что назвал вещи своими именами.

Delphi прекрасный язык, среда и вообще Borland, но время быстро двигается вперед, предоставляя нам новые и новые возможности. Я когда-то использовал это в своих разработках. Все зависит с чем и для чего это делается. Потом многое зависит от того, кто это делает. Если вы хотите быстро (3 дня) создать GUI приложение, которое работает с БД или еще с чем-то, если у вас есть необходимые компоненты (увы большиство из них платные, поэтому их трудно найти, зато легко купить если вы можете себе это позволить). Потом нужно много, много этих компонентов, и создавать свои тоже приходится, но в основном технология оработанная и вам не нужно многое придумывать снова. Если вы не боитесь технической поддержки и готовы с радостью сопровождать свои приложения. Есть приложения, написанные на Delphi, которые приносят реальную пользу. Но, я бы не сказал, что эти приложения пишутся легко. Сам Delphi и pascal уходят корнями в более узкую сферу программирования низкого уровня. Вся эта эйфория от высокоуровнего использования компонентов уже давным давно прошла, хотя многие до сих пор понимают только это. Это была большая стратегическая ошибка, на мой взгляд, со стороны компании, распространяя подобную чушь среди пользователей. С другой стороны pascal и delphi больше подходят для C-шных программистов, которым нравятся альтернативные подходы. Вся беда Delphi в том, что в неопытных руках оно представляет угрозу для критических приложений, а благодаря нашей замечательной системе образования, количество неопытных пользователей катастрофически возрастает. Потому использование Delphi стало еще сложнее. Минусов стало больше чем плюсов, поэтому популярность резко упала. Но это не значит, что pascal или delphi недостойный язык или среда. Приложение, написанное на Delphi — если оно работает правильно — это замечательно, но риск очень большой, порой даже неоправданный, не каждый может себе позволить. Но в этом и есть красота — в особенности.


Раз ты уже не в первый раз меня непрекрыто оскорбляешь я буду называть тебя быдлонедоархитектором, ты ведь не против?
Простите, но я с Вами на брудершафт не пил.

Быдлокодером Вы сами себя идентифицировали: «ты мне ответишь на понятном мне быдлокодерском языке»

Как для уборщицы, понятно?
Раз уж Вы так настаиваете кому какой вопрос задавали... Этот мой вопрос был адресован не Вам, а тому же Софту. Так что не рефлексируйте.

P.S. «Ох уж эти горе-архитекторы...», «Жесть, горе орхетектор-теоретег детектед.» Следили бы за собственным языком, не пришлось бы невинную оскорблённость изображать.

То, что быдлокодеры по узости кругозора

Как для уборщицы, понятно?

Раз ты уже не в первый раз меня непрекрыто оскорбляешь я буду называть тебя быдлонедоархитектором, ты ведь не против?

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

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

И, кстати, меня не интересует Ваше мнение по поводу инкапсуляции.

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

Спор с узколобым пониманием определения инкапсуляции в языке программирования из википедии мне не интересен.

Только создается впечатление что твое широкое и гениальное понятие инкапсуляции родилось исключительно в твоем нездоровом мозгу. Хотя это типичная болезнь быдлонедоархитекторов. Или все таки гениальный быдлонедоархитектор снизойдет до объяснения что такое инкапсуляция в его гениальном понимании?

Андрей
Але з другої сторони така політика призвела до зростання кількості відкритих кодів на делфі, що дуже добре тепер вже можна з чогось вибирати.
Наприклад indy або arrarat synapse та інше по мережі
rem-object pascal, fast script, script in jvcl, web script -по паскальподібних скріптових мовах.
І я не знаю невже таких авторів що пишуть на delphi язик в когось повернеться назвати «формошлёп»?
Чи наприклад автора бібліотеки kol Володимира Кладова.

Чи автора цікавих статей про iнжекти, перехвати системних функцій в 3 та 0 кільцях системи «МS-REMa».

2 prosto

камінь закладенний борланд. Пакунки відкомпільовані різними версіями компіляторів є несумісні.

Те саме у Borland C++ Builder


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

И, кстати, меня не интересует Ваше мнение по поводу инкапсуляции. Вы просили объяснить, я объяснил. Если беседа перешла в разряд «я не согласен», значит Вы не спрашиваете, а спорите. Спор с узколобым пониманием определения инкапсуляции в языке программирования из википедии мне не интересен.

Andrey
О, це правильно- коротко та лаконічно.
(І прибиральниця розбереться якщо вона програміст початківець:))
тема то про делфі.
В мене таке питання по с++. я на ньому не пишу, але мене цікавить як наприклад йде реалізація об’єктів в динамічних бібліотеках,
бо наприклад в делфі щоб це реалізувати треба прокладку модуль писати треба й заново описувати не міняючи методи місцями та визивати можна чомусь тільки віртуальні методи і тд.
І тому в делфі є кращий спосіб пакунки, написав пакунок що зводиться до перечисленя модулів і все користуєшся без ніякої мороки.
Або в проекті поставив галочку «использовать пакеты» і все, прогамма робиться манюнькою й не «здогадується», що вона працює з пакунками. Ну дуже зручно. Але є один камінь закладенний борланд. Пакунки відкомпільовані різними версіями компіляторів є несумісні.

Ну і тому я думою що повинні бути й в візуалі бути якісь зручності з цього приводу.

Где-то прочитал что обычно люди спорят о том в чем они меньше всего разбираются

На этой фразе можно лишь сказать «занавес» в этом театре абсурда...

Всем

Наследование — частный случай инкапсуляции, когда инкапсулируется целиком класс, а не отдельные поля

А модифицированный мной пример про TDocument Вы не читали, не поняли или проигнорировали как неудобный?

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

Там популярно разжовывается понятие инкапсуляции и её применение при проектировании.

А я спрашивал Софт (а не тебя) о понятии архитектурной инкапсуляции!

том числе на этот. Почитайте, в самом деле. Именно эта книга весьма интересна и очень легко читается.

Как то не нашел. Ну и я больше доверяю мнениям Буча и Страуструпа.

Но это все равно не обьясняет где в твоем примере инкапсуляция, и как она заменяет наследование.

А модифицированный мной пример про TDocument Вы не читали, не поняли или проигнорировали как неудобный?


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

Там вводится понятие архитектурной инкапсуляции?

Там популярно разжовывается понятие инкапсуляции и её применение при проектировании.

Википедия — неавторитетный источник.
Но в ней есть ссылки на авторитетные источники.

В том числе на этот. Почитайте, в самом деле. Именно эта книга весьма интересна и очень легко читается.

Обычный С, не С++ и объекты ядра в kernel-development. Где объектом выступает структура данных которая однозначно определяет объект и его свойства, а поля которые не для изменений откоментированны в документации. В данном случае принципы ООП контролирует не компилятор, а программист.

Ок, я согласен, что неформально такая мысль имеет право на существование, но формально это не язык позволяет такое устроить, а процесс документирования и использования только документированной функциональности.

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

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

Но это все равно не обьясняет где в твоем примере инкапсуляция, и как она заменяет наследование.


Паря 12 мин. назад
WTF архитектурная инкапсуляция? Можно дать ссылки на авторитетные источники с обьяснением этого термина?
Согласно википедии, инкапсуляция это -
A language mechanism for restricting access to some of the object’s components.
A language construct that facilitates the bundling of data with the methods operating on that data

Я не видел ни одного процедурного языка который бы позволял делать такие штуки, может подскажеш?

Обычный С, не С++ и объекты ядра в kernel-development. Где объектом выступает структура данных которая однозначно определяет объект и его свойства, а поля которые не для изменений откоментированны в документации. В данном случае принципы ООП контролирует не компилятор, а программист.

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

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

Там вводится понятие архитектурной инкапсуляции?

Википедия — неавторитетный источник.

Но в ней есть ссылки на авторитетные источники.

Можно дать ссылки на авторитетные источники с обьяснением этого термина?

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

Согласно википедии...

Википедия — неавторитетный источник.

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

Ах, да, Вы определенно правы. Как это ни странно звучит, быдлокодеров и среди аналитиков валом. Мне такой заявлял «я задокументирую за заказчиком всё, что он говорил, дам на подпись, а после реализации этих требований пусть не говорит, что программа не устраивает» — чистейший быдлокодинг требований.

Поэтому говорите с людьми на понятном им языке.

Я так и делаю — называю своими именами то, что вижу:)

троллей не кормлю

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


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

Речь шла про архитектурную инкапсуляцию, которая разрабатывается еще до создания скелетов классов на каком-либо языке. В данном случае архитектурная инкапсуляция возможна даже на чисто процедурных языках, так как это не функционал языка, а логическое соглашение.

WTF архитектурная инкапсуляция? Можно дать ссылки на авторитетные источники с обьяснением этого термина?
Согласно википедии, инкапсуляция это -
A language mechanism for restricting access to some of the object’s components.
A language construct that facilitates the bundling of data with the methods operating on that data

Я не видел ни одного процедурного языка который бы позволял делать такие штуки, может подскажеш?

2 Паря:
троллей не кормлю
2 Soft
В Вашем примере изменена структура наследования, но это не инкапсуляция. Раз уж Вы взяли пример, связанный с документом, попробую модифицировать его.
Есть класс TDocument, который знает о документе всё: разбивку на структурные элементы, оформление, форматирование. У TDocument есть методы saveToStream и loadFromStream, позволяющие сохранить и загрузить документ. Пусть это будет в формате txt, т.е. с потерей форматирования.
Вполне естественно для DOC, HTML, WIKI (есть идея в свой редактор wiki добавить:) и т.д. сделать соответствующие наследники от TDocument... Но это неверно. А верно — завести абстрактный класс TTextFilter, про который знает TDocument и методы которого будет использовать. TTextFilter отвечает за чтение и запись текста в поток в соответствующем формате. TdocFilter, ThtmlFilter и т.д. — его наследники, но TDocument о них не знает, это и есть инкапсуляция.

Как для уборщицы, понятно?


Паря 16 мин. назад

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

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

Речь шла про архитектурную инкапсуляцию, которая разрабатывается еще до создания скелетов классов на каком-либо языке. В данном случае архитектурная инкапсуляция возможна даже на чисто процедурных языках, так как это не функционал языка, а логическое соглашение.


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

Поэтому говорите с людьми на понятном им языке.

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


Василий Чобиток 2 мин. назад
2 Soft:

Ну что получилось уборщице?; -)) Поверьте, я после КВТИУ бойцам «от сохи» весьма сложные вещи объяснял, не говоря уже про юристов.

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

Поэтому говорите с людьми на понятном им языке.

Ну что получилось уборщице?; -)) Поверьте, я после КВТИУ бойцам «от сохи» весьма сложные вещи объяснял, не говоря уже про юристов. Просто здесь не ожидал наткнуться на столь глубокую дремучесть, поэтому, извините, сразу как-то и не попытался объяснять «как для уборщицы».

А по сути ответить как обычно слабо, ну-ну.

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

2 Soft:

Ну что получилось уборщице?; -)) Поверьте, я после КВТИУ бойцам «от сохи» весьма сложные вещи объяснял, не говоря уже про юристов. Просто здесь не ожидал наткнуться на столь глубокую дремучесть, поэтому, извините, сразу как-то и не попытался объяснять «как для уборщицы».

оймите, кроме инкапсуляции на конкретном уровне OOP есть инкапсуляция на более высоких уровнях OOD и OOA.

Жесть, горе орхетектор-теоретег детектед.

Замените «инкапсулировали» на «упаковали функционал» и всё будет понятно. Просто вы пытаетесь известному термину определить новое определение.

Вы что?! При чём тут я?!

«Инкапсулировать изменчивую часть» — это классика, это не я известному термину новое значение придумал, это к классикам. Поймите, кроме инкапсуляции на конкретном уровне OOP есть инкапсуляция на более высоких уровнях OOD и OOA. При этом, применение инкапсуляции на уровне анализа совершенно не зависит от того есть ли в языке программирования вообще возможности объявлять видимость свойств и методов классов и является ли вообще язык объектно-ориентированным.


Пример: фабрика классов для открытия разных документов.
Есть мастер-класс TDocument от него напрямую наследуются TTXTDocument, TWordDocument, TRtfDocument, вместо того чтобы TWordDocument, TRtfDocument наследовать от TTXTDocument.

Так что здесь используется и наследование и инкапсуляция. Но в первом случае кроме инкапсуляции в стандартном понимании этого термина идёт упаковка функционала вместо размазывания его по куче наследников.

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

С семантической парадигмой что-то не то, в совокупности не совсем понятно...

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

прошу пример, который показывает как наследование заменяется инкапсуляцией

Пример: фабрика классов для открытия разных документов.
Есть мастер-класс TDocument от него напрямую наследуются TTXTDocument, TWordDocument, TRtfDocument, вместо того чтобы TWordDocument, TRtfDocument наследовать от TTXTDocument.

Так что здесь используется и наследование и инкапсуляция. Но в первом случае кроме инкапсуляции в стандартном понимании этого термина идёт упаковка функционала вместо размазывания его по куче наследников.

2 Soft:

Просто отвяжите вашу семантическую парадигму от well known words, иначе все слова понятны, но в совокупности неясно что ими хотел сказать автор.

Попробую этот хороший совет обратить к Вам.

Цитата 1:

Это ж надо, такую ахинею с таким умным лицом несёт!

Цитата 2:

Нет я как раз понял что вы сказали и использовал это в технологии...

Иными словами, в упомянутой технологии Вы использовали ту ахинею которую я нёс с таким умным лицом?;:)

С семантической парадигмой что-то не то, в совокупности не совсем понятно...


мы вынесли изменчивую часть за скобки — инкапсулировали
Замените «инкапсулировали» на «упаковали функционал» и всё будет понятно. Просто вы пытаетесь известному термину определить новое определение.

Так как под инкапсуляцией здесь понимается не инкапсуляция полей объекта, а (инкапсуляция кода + полей) или определённого процессинга.

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

Вот вот, как бы появляются подозрения.


Чем Вас не устроил этот пример?
Мне несложно привести примеров. Но для адекватности примера следует знать уровень подготовки аудитории. Сходу привел шаблон Стратегия — аудитория не воспринимает...
Ну, ладно, попытка № 2: см. пример по ссылке (первые разделы можете смело пропустить и см. Часть 3. Программная реализация). Будет непонятно — сообщите, попробую что-нибудь на элементарном уровне.

В примере использован шаблон проектирования Стратегия. При этом, применяя некоторые особенности языка PHP, к классу distribution подключаются конкретные алгоритмы распределения вообще без объявления абстрактного алгоритма распределения. Вот так, при появлении новых (изменении старых) требований, вместо того, чтобы плодить наследников от класса distribution, мы вынесли изменчивую часть за скобки — инкапсулировали.

Отлично, я на фразу

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

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

Чем Вас не устроил этот пример?
Мне несложно привести примеров. Но для адекватности примера следует знать уровень подготовки аудитории. Сходу привел шаблон Стратегия — аудитория не воспринимает...
Ну, ладно, попытка № 2: см. пример по ссылке (первые разделы можете смело пропустить и см. Часть 3. Программная реализация). Будет непонятно — сообщите, попробую что-нибудь на элементарном уровне.

В примере использован шаблон проектирования Стратегия. При этом, применяя некоторые особенности языка PHP, к классу distribution подключаются конкретные алгоритмы распределения вообще без объявления абстрактного алгоритма распределения. Вот так, при появлении новых (изменении старых) требований, вместо того, чтобы плодить наследников от класса distribution, мы вынесли изменчивую часть за скобки — инкапсулировали.

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


Паря 7 мин. назад

Ох уж эти горе-архитекторы — спрашываешь привести простенький примерчик, и попадаешь под град заумных терминов и отсыланию к толстым книгам.

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

Чуть похоже на антипаттерн «божественный-модуль», но содержит не весь функционал системы, а только тот, который логически неделим в рамках определённого процесса.

Ох уж эти горе-архитекторы — спрашываешь привести простенький примерчик, и попадаешь под град заумных терминов и отсыланию к толстым книгам.


Василий Чобиток 21 мин. назад
2 Soft: по сути сказанного в последнем абзаце Вы правы. Но Вы таки не поняли сказанное мной (впрочем, формат кратких реплик не позволяет адекватно «раскрыть тему»), поэтому сделали неверные выводы.

Попробуйте почитать упомянутую мной книгу А. Шаллоуея.

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

Просто отвяжите вашу семантическую парадигму от well known words, иначе все слова понятны, но в совокупности неясно что ими хотел сказать автор.

2 Soft: по сути сказанного в последнем абзаце Вы правы. Но Вы таки не поняли сказанное мной (впрочем, формат кратких реплик не позволяет адекватно «раскрыть тему»), поэтому сделали неверные выводы.

Попробуйте почитать упомянутую мной книгу А. Шаллоуея.

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

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

Инкапсуляция — по сути упаковка функционала внутрь неделимого объекта. А наследование здесь вообще ни причем. Оно может как использоваться так и нет. Но к инкапсуляции оно никаким боком не лежало.

Это ж надо, такую ахинею с таким умным лицом несёт!

Не можете вести дискуссию, зачем троллить?

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


Я дал ссылку на пример шаблона проектирования Стратегия. Вообще многие шаблоны проектирования построены на использовании инкапсуляции вместо наследования.

Если вы понимаете, что требования неизбежно изменчивы, в том числе и на поздних стадиях проекта, то должны понимать, что в ранее написанный код будут вноситься изменения. Есть два способа на этапе проектирования предусмотреть будущие изменения: изменять реализацию классов путём наследования или инкапсулировать изменчивую часть. Конкретный пример для шаблона Адаптер. Абстрактный класс DB не только вводит единую спецификацию доступа к базе данных, но и инкапсулирует изменчивую часть от основной системы — при переходе на новую СУБД основная система не затрагивается вообще.

Это ж надо, такую ахинею с таким умным лицом несёт!

Просто в этой фразе

При появлении нового функционала они без зазрения совести наследуются, хотя правильно было бы инкапсулировать

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

Именно! Здесь наследование инкапсулировано от основной системы. Для основной системы класс DB — черный ящик, предоставляющий единые методы доступа к БД, а как именно этот доступ организован, наследованием или как-то ещё от основной системы инкапсулировано.
Если интересно, рекомендую почитать эту книгу: «Шаллоуей, Алан, Тротт, Джейм, Р. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию: Пер. с англ. —М.: Издательский дом „Вильямс“, 2002.»

Цитата:

Инкапсуляция — это не просто сокрытие данных. Такое слишком узкое представление ограничивает возможности проектировщика.

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

Ну в приведенном примере инкапсуляция отлично уживается с наследованием, не понял примера.

Дык, а что конкретно плохого в наследовании, и чем инкапсуляция принципиально лучше, можно короткий вменяемый пример?

Я дал ссылку на пример шаблона проектирования Стратегия. Вообще многие шаблоны проектирования построены на использовании инкапсуляции вместо наследования.

Если вы понимаете, что требования неизбежно изменчивы, в том числе и на поздних стадиях проекта, то должны понимать, что в ранее написанный код будут вноситься изменения. Есть два способа на этапе проектирования предусмотреть будущие изменения: изменять реализацию классов путём наследования или инкапсулировать изменчивую часть. Конкретный пример для шаблона Адаптер. Абстрактный класс DB не только вводит единую спецификацию доступа к базе данных, но и инкапсулирует изменчивую часть от основной системы — при переходе на новую СУБД основная система не затрагивается вообще.

Дык, а что конкретно плохого в наследовании, и чем инкапсуляция принципиально лучше, можно короткий вменяемый пример?

Помоему сообщество «Делфи Мастерс» стоит переименовать в «Фрунзе»...

Штопор лучше отвертки, двери дыр, а в природе всего есть определение ничего? Дайте еще пыхнуть, мистер Андерсон. Вы о чем?

Я о том, чего катастрофически не хватает многим кодерам — понимания пройденного при обучении или прочтённого в Википедии. При появлении нового функционала они без зазрения совести наследуются, хотя правильно было бы инкапсулировать. Не в узком смысле приведенного определения инкапсуляции в языке программирования, а на уровне анализа и проектирования.
Для тренировки, попробуйте здесь найти инкапсуляцию и понять чем она лучше наследования (только не ищите в примерах кода!!!).

Если Вы под инкапсуляцией понимаете только объявление приватных методов, для кодера это не страшно и нормально. Но такое понимание недопустимо для аналитика и архитектора.


Василий Чобиток 5 мин. назад
Золотые слова!

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

Штопор лучше отвертки, двери дыр, а в природе всего есть определение ничего? Дайте еще пыхнуть, мистер Андерсон. Вы о чем?

Инкапсуля́ция — свойство языка программирования, позволяющее объединить и защитить данные и код в объект и скрыть реализацию объекта от пользователя (прикладного программиста). При этом пользователю предоставляется только спецификация (интерфейс) объекта.

ru.wikipedia.org/...ограммирование

А множественное наследование прекрасно заменяется инкапсуляцией вместо неоднозначностей.

Золотые слова!

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

А динамическое выделение памяти это четвертый принцип ООП?

Нет, это одно из правил kernel-development, не загаживай стек. Если создавать кучу объектов на стеке можно и вылететь в синий экран.

А плавающую точку в обработчиках прерываний?

В Passive Mode IRQL использую, там нет никакой магии, всё расписано.

Кстати, а эксепшены вы часом в коде ядра не используете?

Я их и в своём обычном коде стараюсь не использовать, проще через передачу статуса выполнения функции. Хотя есть реализация для Passive Mode библиотеки STL, там и екзепшены есть.

Потому что основной смысл ООП сделать сложность всей системы не выше максимальной сложности объекта используемого в системе.

А динамическое выделение памяти это четвертый принцип ООП?
Кстати, а эксепшены вы часом в коде ядра не используете?

А плавающую точку в обработчиках прерываний?


eugene_n 3 мин. назад

А зачем?

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

А так вообще нафиг не надо. Кто пишет не на чистом асме — ламер мастайный непингуемый. А всякие Java/.NET программисты не программисты даже, а конфигурасты фреймворков.

Вот создайте этот класс выделив под него память в нестраничном пуле без перегрузки оператора new

А зачем?

Вот создайте этот класс выделив под него память в нестраничном пуле без перегрузки оператора new

class CMyClass {
public:
CMyClass () {;};
protected:

int i; };


eugene_n 1 мин. назад
Да, не представляю как этой функцией в С++ выделить память под объект.

В ядре?

Да.

Да, не представляю как этой функцией в С++ выделить память под объект.

В ядре?

В Delphi для этого нужно перегружать функцию NewInstance. Суть та же.

А если бы это был не оператор new, а вызов функции MyIncredibleMalloc () в логике программы что-нибудь бы изменилось?

Да, не представляю как этой функцией в С++ выделить память под объект.

А если бы это был не оператор new, а вызов функции MyIncredibleMalloc () в логике программы что-нибудь бы изменилось?


eugene_n 15 мин. назад
Вижу комплект оберток вокруг ExAllocatePoolWithTag / ExFreePoolWithTag.
Не вижу необходимости делать для этого перезагрузку операторов.
А new/delete это по вашему что? В стандарте языка это операторы.

И вообще как без этой перегрузки выделить память в нестраничной области памяти под объект класса. Или вы сейчас начнёте говорить нафиг там клаcсы?


Не вижу необходимости делать для этого перезагрузку операторов.
Ну как же, крутой пацан-крестовик просто обязан наперегружать операторов, создать несколько ненужный иерархий классов, обязательно применить паттерны (где надо и не надо), а для подтверждения своей полной крутизны продемонстрировать знания Александреску написать пару-тройку хитробы! баных шаблонов.

Это такая форма фаллометрии (теперь уже ретрофаллометрии из девяностых).

Вижу комплект оберток вокруг ExAllocatePoolWithTag / ExFreePoolWithTag.

Не вижу необходимости делать для этого перезагрузку операторов.

А с этого места можно подробнее?

#ifndef _cppmem_h_
#define _cppmem_h_

extern "C" {
#include <ntddk.h>
}

//standart teg for memory management
#define __STANDARTMEM_TAG 'CPME'

/*******************************************************************************
	new/delete overloading
*******************************************************************************/
inline void* __cdecl operator new(size_t _BlockSize)
{
  PAGED_CODE();
  PVOID result = ExAllocatePoolWithTag(PagedPool, _BlockSize, __STANDARTMEM_TAG);

if (result)
		RtlZeroMemory(result, _BlockSize);
	return result;
}

inline void* __cdecl operator new[](size_t _BlockSize)
{
  PAGED_CODE();
  PVOID result = ExAllocatePoolWithTag(PagedPool, _BlockSize, __STANDARTMEM_TAG);

if (result)
		RtlZeroMemory(result, _BlockSize);
	return result;
}

inline void* __cdecl operator new(size_t _BlockSize, POOL_TYPE _poolType)
{
  PVOID result = ExAllocatePoolWithTag(_poolType, _BlockSize, __STANDARTMEM_TAG);

if (result)
		RtlZeroMemory(result, _BlockSize);
	return result;
}

inline void* __cdecl operator new[](size_t _BlockSize, POOL_TYPE _poolType)
{
  PVOID result = ExAllocatePoolWithTag(_poolType, _BlockSize, __STANDARTMEM_TAG);

if (result)
		RtlZeroMemory(result, _BlockSize);
	return result;
}

inline void* __cdecl operator new(size_t _BlockSize, POOL_TYPE _poolType, ULONG _tag)
{
  PVOID result = ExAllocatePoolWithTag(_poolType, _BlockSize, _tag);

if (result)
		RtlZeroMemory(result, _BlockSize);
	return result;
}

inline void* __cdecl operator new[](size_t _BlockSize, POOL_TYPE _poolType, ULONG _tag)
{
  PVOID result = ExAllocatePoolWithTag(_poolType, _BlockSize, _tag);

if (result)
		RtlZeroMemory(result, _BlockSize);
	return result;
}

inline void __cdecl operator delete( void *p )
{
  if (!p)
    return;

ExFreePoolWithTag(p, __STANDARTMEM_TAG);
}

inline void __cdecl operator delete[]( void *p )
{
  if (!p)
    return;

ExFreePoolWithTag(p, __STANDARTMEM_TAG);
}

inline void __cdecl operator delete( void *p, ULONG _tag)
{
  if (!p)
    return;

ExFreePoolWithTag(p, _tag);
}

inline void __cdecl operator delete[]( void *p, ULONG _tag)
{
  if (!p)
    return;

ExFreePoolWithTag(p, _tag);
}

#endif //_cppmem_h_

В некоторых случаях перегузка операторов очень удобна, например при разработке драйверов режима ядра просто необходимо перегружать new/delete причем иногда приходится делать специальные перегрузки этих операторов для определенных классов для использования страничной и нестраничной памяти

А с этого места можно подробнее?

А множественное наследование прекрасно заменяется инкапсуляцией вместо неоднозначностей.

Что вы хотели этим сказать я не совсем понял, но как знаете.

2 Soft

Для векторно-матричных библиотек тоже довольно удобно.

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


Андрей 1 час назад
2 silverwolf

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

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

А то же множественное наследование есть и в Java, и в Delphi, и в C# в той форме в которой оно тоже просто необходимо — в виде интерфейсов. А Труп Штрауса был очень ленив чтобы сделать в С++ по человечески.

Название камня в студию.

Камень не помню, железо не я делал, камень поддерживал систему команд MSC52 (расширенный MSC51). Мне было этого вполне достаточно + протоколы общения с периферией.
Среда разработки какой-то тыреный IAR не помню уже какой версии.
Ну в общем да, тогда писал на чистом С.

Просто сейчас даже для kernel-drivers стараюсь использовать С++, так как удобнее. Если не особо шаманить с наворотами С++ типа темплейтов, конструкторов копирования (использовать объекты только через ссылку или указатель), не особо увлекаться многоуровневым множественным наследованием с виртуальными функциями, то по скорости и надёжности не отличается от обычного С.

2 silverwolf

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

Ой...такой срач пропустил...как я мог...

Некоторое время писал на С++ под MSC51

Название камня в студию. И еще название среды разработки.

Мне кажется вы немного преувеличиваете.


В общем да, кооперативная многозадачность. Преимущества в простоте реализации ОС и её малом размере.

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

Когда на чипе 4K памяти ОЗУ, то размер ОС имеет значение.


Многие для embedded пишут свою собственную ОС. Из преимуществ этого подхода: объем ОС около 2 Кб, корпоративный параллелизм и использование только того что нужно.

То ты embed’а не нюхал...

Некоторое время писал на С++ под MSC51, но да, особо не работал. Основное моё направление разработка системного ПО под Win32/Win64 и различные интеграции системной части кода с другими проектами.


Еще одна неплохая попытка:)

Тоесть Вы конечно же в курсе перечисленных выше языков и сейчас выскажите аргументированное мнение о превосходстве крестиков на одными?

Хорошо, давайте заканчивать.

Да, давайте, не думаю что от Вас мы услышим что-то толковое.

Вот найдеться здесь хоть один программист на Жаве который смело выйдет вперед и честно скажет «да, я пишу просто корпоративную систему с несложной логикой»?

Сейчас не знаю, 3 года назад Я писал просто корпоративное приложение с 1 модулем сложной логики, остальное CRUD. Тогда моим «фетишем» был «логичный и структурированный код», а также стыдно вспомнить TDD.

А можно узнать что именно и как долго Вы на нем писали?

Как на основном языке (то есть, тот за который мне платили деньги) всего 1 год. Но понимать его удобства уже когда пару лет поработал с Java.

но с Вашим уровнем я дажене смею рассчитывать

Еще одна неплохая попытка:)

Тогда почему Вы активно продолжаете обсуждать со мной С++?

Хорошо, давайте заканчивать.


Эта фраза исключительно из желания нахамить, или есть действительно повод так считать?

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

Помоему в этой ветке никто не обсуждал «тогда», а все (кроме тебя) обсуждают «сейчас».

Для любителей «сейчас» я отписал несколько названий в прошлом посте. Но они никогда не получат высокого распространения по все тем же причинам: имплементации, библиотеки, готовые спецы.


Enterprise — не всегда «написание корпоративных систем с несложной логикой» бывают и высоконагруженные приложения со сложной логикой.

Вы знаете, последние годы слово «высоконагруженный» стало таки прямо фетишем точкаНЕТчиков и Жабакодеров. Типо «я не быдлокодер, моя система высоконагруженная! ». Вот найдеться здесь хоть один программист на Жаве который смело выйдет вперед и честно скажет «да, я пишу просто корпоративную систему с несложной логикой»?

Та в том то и дело что ЦПП — таки очень удобный инструмент, просто надо «уметь его готовить».
А можно узнать что именно и как долго Вы на нем писали?

Повторяю еще раз (для особо высоконагруженных): есть значительно более интересные языки для моей области (BitC, Cyclone, новострой Go), но с Вашим уровнем я дажене смею рассчитывать что вы хотя бы слышали такие названия (да и фамилии Шапиро, Пайк, Томсон)

Тут обсуждается Delphi, а не C++

Тогда почему Вы активно продолжаете обсуждать со мной С++?

2anonymous

Судя по тому что у вас в профиле сплошная жава и ынтырпрайз Вас уже «отсеяли», да?

Хорошая попытка:) Java я выбрал сознательно (после некоторого времени работы с C++), при чем в основном по «философским» проблемам.

Enterprise — не всегда «написание корпоративных систем с несложной логикой» бывают и высоконагруженные приложения со сложной логикой.

Вообще странная позиция, считать неудобство инструмента преимуществом...

Та в том то и дело что ЦПП — таки очень удобный инструмент, просто надо «уметь его готовить».
Повторюсь:
Тут обсуждается Delphi, а не C++

Если есть желание обсудить смерть ЦПП — откройте отдельную тему, кстати у меня была где-то закладка с постов «ЦПП умер, но все еще пахнет» (или что-то в этом роде)

Тоесть вы с третьей попытки это таки поняли?

Эта фраза исключительно из желания нахамить, или есть действительно повод так считать?

Вот только когда то С++ совершенно не был «мажорной» платформой, да и в посудную лавку эмбеда такого слона запустили относительно недавно...

Помоему в этой ветке никто не обсуждал «тогда», а все (кроме тебя) обсуждают «сейчас».


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

Вот только когда то С++ совершенно не был «мажорной» платформой, да и в посудную лавку эмбеда такого слона запустили относительно недавно...


Для «быдлоформочек» есть QT.

Этот рынок у СРешетки никакой Кьют уже не отберет. А учитывая какими темпами новый владелец Кьюта Нокия про! бывает рынок смартфонов можно смело сделать ставку, что Кьют так и останется игрушкой КДЕшников.

Вопрос к спецам по.Net: Можно ли использовать C++ при работе с ASP.NET? Мне говорили что можно, но утверждать не буду.

Я не спец по по точкаНЕТ, но предположу что мэнэджед кресты можно использовать с АСПом. А еще можно бриться газонокосилкой... Вы мне доказываете удобство или теоретическую возможность? Вы не думаете, что уход крестиков из этой ниши имеет под собой реальные основания? (нет, не заговор ЗОГ)

Вот тут дилемма. Если необходима быстрая заменяемость (написание корпоративных систем с несложной логикой или «сайтиков» ), то это недостаток. Если необходимо необходимо построить качественное приложение, то сложность языка (сложность окружения, точнее) — это плюс, сложный язык (окружение) позволит отсеять «случайных людей».
Судя по тому что у вас в профиле сплошная жава и ынтырпрайз Вас уже «отсеяли», да?

Вообще странная позиция, считать неудобство инструмента преимуществом...

Только почему вы его сравниваете с всякими жабами? Сравнивать стоит с тем же Паскалем (на котором в свое время немало написали под системы, значительно более ограниченные, чем 99 процентов современного эмбеда), Фортраном или с Адой.

Я сравниваю с тем в чем разбираюсь, в отношении остального доверяю публичным бенчмаркам. Ну и считаю некоректным сравнивать С++ с минорными платформами, всегда смотрел на первую десятку TIOBE, так как минорные платформы проигрывают по многим другим параметрам (комьюнити, библиотеки, средства разработки и т.д.)


Думаю отсутствие фич (например в джава куча ран тайм информации привязанной к каждому обьекту и которая потребляет память).
Ого, я уже было оставил надежду увидеть в этом треде вменяемые мысли.:)

Только почему вы его сравниваете с всякими жабами? Сравнивать стоит с тем же Паскалем (на котором в свое время немало написали под системы, значительно более ограниченные, чем 99 процентов современного эмбеда), Фортраном или с Адой. В конечном итоге все решила обратная совместимость с Ц, победа Венды на десктопах и правильный пиар от дедушки Страуса (типо новый улучшенный Ц от самой АТнТ, в то время как ведущие сотрудники оной до сих пор всеми силами от С++ открещиваются (каламбур)).

Раскроете тему «хорошести» крестиков для написания инет магазина или быдлоформочки?

Для «быдлоформочек» есть QT.

Вопрос к спецам по.Net: Можно ли использовать C++ при работе с ASP.NET? Мне говорили что можно, но утверждать не буду.

высокая сложность освоения языка — это преимущество или недостаток для его коммерческого применения?

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

Небольшое напоминание: Тут обсуждается Delphi, а не C++.

Доргой эксперт, может вы изложите свое ценное мнение относительно того, какие фичи _языка_ (а не современных, шлифуемых десятилетиями реализаций) С++ делают его недосягаемым для конкурентов в области производительности и «оптимизации по ресурсам»?

Думаю отсутствие фич (например в джава куча ран тайм информации привязанной к каждому обьекту и которая потребляет память).


Все таки не только поэтому, но и потому что в плане производительности и оптимизации по ресурсам С/С++ нету конкурентов (ну кроме ассемблера)

Доргой эксперт, может вы изложите свое ценное мнение относительно того, какие фичи _языка_ (а не современных, шлифуемых десятилетиями реализаций) С++ делают его недосягаемым для конкурентов в области производительности и «оптимизации по ресурсам»?

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

Все таки не только поэтому, но и потому что в плане производительности и оптимизации по ресурсам С/С++ нету конкурентов (ну кроме ассемблера)


C++ хорош абсолютно для всего (в этом его основное преимущество)

Раскроете тему «хорошести» крестиков для написания инет магазина или быдлоформочки?

вот только для того что бы с ним работать надо иметь довольно высокую подготовку.

Капитан очевидность, вы как всегда вовремя! Теперь вдумайтесь: высокая сложность освоения языка — это преимущество или недостаток для его коммерческого применения? (для возведения в объект надроча и поднятия ЧСВ однозначно плюс, только в этой области шаблоны и паттерны давно вытеснили замыкания и монады)


А на чём же вы пишите для ембедед. На Java?

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

В общем да, кооперативная многозадачность. Преимущества в простоте реализации ОС и её малом размере.

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

Многие для embedded пишут свою собственную ОС. Из преимуществ этого подхода: объем ОС около 2 Кб, корпоративный параллелизм и использование только того что нужно.

То ты embed’а не нюхал...

Я Вам открою секрет: в 21 веке С++ как язык не хорошь вообще ни для чего,

C++ хорош абсолютно для всего (в этом его основное преимущество), вот только для того что бы с ним работать надо иметь довольно высокую подготовку.


Я Вам открою секрет: в 21 веке С++ как язык не хорошь вообще ни для чего, приходиться его использовать именно потому что есть высококачественные реализации и библиотеки. Делфи же на данный момент не хорош вообще ни в чем.
А на чём же вы пишите для ембедед. На Java?
ru.wikipedia.org/wiki/Jazelle
Ну и собственно на чем писать высокотребовательное ПО для мультимедия-процессинга под ту же Win32? На С# и Java лагает страшно, если их не использовать для вебморды. А решения для Delphi есть

www.mitov.com/...l/videolab.html

это я так подозреваю кооперативная многозадачность? Раскроете мысль чем это по вашему является преимуществом над вытесняющей?
В общем да, кооперативная многозадачность. Преимущества в простоте реализации ОС и её малом размере.
>> Кстати мы таки услышим развитие мысли о «сервеной среде ВхВокс»?

Embeded ОС это не классические ОС, это по сути оболочки для прошивок. Так как если их классифицировать как ОС, то любой код занимающийся переключением задач и реализацией некоторого системного API есть уже ОС. Ну, а де-факто современные ОС уже давно выросли из давнего определения.

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

Оо! У Бродского работают программисты, респект!


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

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

Многие для embedded пишут свою собственную ОС. Из преимуществ этого подхода: объем ОС около 2 Кб, корпоративный параллелизм и использование только того что нужно.

Да Вы я вижу еще и в эмбедеде эксперт! Скажите, а многие это кто? «Копроративный паралеллизм» это я так подозреваю кооперативная многозадачность? Раскроете мысль чем это по вашему является преимуществом над вытесняющей? Кстати мы таки услышим развитие мысли о «сервеной среде ВхВокс»?

безусловно качественное окончание дня. каждый вечер бы так.

безусловно качественное окончание дня. каждый вечер бы так.

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

Угу. А именно это и требуют заказчики от C/С++ кода так как просто код им не нужен.


Тем что для обработки больших объемов данных для тех же типов int16, int32, int64 иногда приходится писать разный код, особенно если используется особенности архитектуры машины, как MMX, SSE, что иногда повышает производительность от 40−300%.

Где-то была библиотека для быстрой обработки строк на С++ с использованием фич SIMD, так вот там для char и wchar_t писали несколько отличающийся код.

То есть на самом деле речь идет не о

шаблоны выроджают скорость работы C++ программ до скорости.NET

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


На тему ВхВокса как серверной среды тоже было бы интересно послушать.

Думаю такая тема заслуживает написание как минимум кандидатской!

Многие для embedded пишут свою собственную ОС. Из преимуществ этого подхода: объем ОС около 2 Кб, корпоративный параллелизм и использование только того что нужно.

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

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

Анонимная функция procedure of object по сути является замыканием (делегатом) так как при её вызове неявно передаётся аргумент Self, того объекта к которому она принадлежит. Используется для вызова событий или для создания callback функций. В C++ настолько удобный механизм реализовывался через хитрый темплейтовый хак FastDelegate
www.codeproject.com/...stDelegate.aspx
>> Дорогой эксперт, можете пожалуйста развить мысль?:)
Тем что для обработки больших объемов данных для тех же типов int16, int32, int64 иногда приходится писать разный код, особенно если используется особенности архитектуры машины, как MMX, SSE, что иногда повышает производительность от 40−300%.

Где-то была библиотека для быстрой обработки строк на С++ с использованием фич SIMD, так вот там для char и wchar_t писали несколько отличающийся код.


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

Думаю такая тема заслуживает написание как минимум кандидатской!

Какая разница, есть ли шаблоны, перегрузка оператора,...?
Заходите, например, job.ukr.net, в поле «Ищу работу» вбиваете «Delphi», получаете результат в виде всего лишь двух страничек, и это в вакансиях, включая в понятие «программист», дополнительно сопровождение всяких 1С, PHP и «помогать пользователям...». Засветившиеся зарплаты 3 тыс, 6 тыс, 800$,..., а больше как-то и нет.
Делаю тоже самое, хотя бы, с JAVA или.NET и получаю намного более оптимистичные результат во всех отношениях.
Delphi — прекрасный инструмент для своих задач, но рынок труда его уже похоронил.

Кстати, в банках еще можно встретить софт на DBase, который продолжает развиваться местными программистами-админами в одном лице.:)


Это 5! Ты сделал мой день. Особенно порадовала каша в голове где эксперт путает ананимные функции, замыкания и почему то называет все это эвентом. Наверное потому что на обработчики событий удобно биндить анонимные функции и замыкания?

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


А вот отсутствие виртуальных конструкторов в С++ и анонимных замыканий (events) делают особо муторной реализацию в С++ некоторых паттернов про реализацию которых в Delphi даже не думаешь, оно в самом стандарте языка.

Это 5! Ты сделал мой день. Особенно порадовала каша в голове где эксперт путает ананимные функции, замыкания и почему то называет все это эвентом. Наверное потому что на обработчики событий удобно биндить анонимные функции и замыкания?

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

Дорогой эксперт, можете пожалуйста развить мысль?:)


anonymous 24 мин. назад

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

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

Дорогой делфимастер, расскажите пожалуйста чем по Вашему авторитетному мнению вызов перегруженого оператора отличается от вызова функции?

Перегруженный оператор ничем, так как по сути та же самая функция. И не вижу необходимости в операторах, когда можно использовать функцию.
А вот отсутствие виртуальных конструкторов в С++ и анонимных замыканий (events) делают особо муторной реализацию в С++ некоторых паттернов про реализацию которых в Delphi даже не думаешь, оно в самом стандарте языка.

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


Кроме того всякая перегрузка операторов и шаблоны выроджают скорость работы C++ программ до скорости.NET.

Дорогой делфимастер, расскажите пожалуйста чем по Вашему авторитетному мнению вызов перегруженого оператора отличается от вызова функции?

А заодно, как именно шаблоны убивают производительность; -)

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


Кроме того всякая перегрузка операторов и шаблоны выроджают скорость работы C++ программ до скорости.NET.

Дорогой делфимастер, расскажите пожалуйста чем по Вашему авторитетному мнению вызов перегруженого оператора отличается от вызова функции?


Че правда? В C есть перегрузку операторов, шаблоны?

Не обращая внимание, это гость из середины девяностых... Разморозили видимо недавно.


silverwolf 8 мин. назад

Че правда? В C есть перегрузку операторов, шаблоны?

Зато в С++ нет GUI с коробки. Конечно есть QT и wxWidgets, но их нужно прикручивать. MFC это вообще бред сумасшедшего, почему же сейчас на С++ под Windows GUI уже не пишут.

Кроме того всякая перегрузка операторов и шаблоны выроджают скорость работы C++ программ до скорости.NET. С хорош для высокопроизводительной работы ПО, а это стиль С-с-классами. Как только начинается магия-компилятора имеем падение в производительности критических участков кода в 2−3 раза.

Останні версії делфі мають все чим колись гордились сішники — перегрузку операторів, шаблони і тд.

Че правда? В C есть перегрузку операторов, шаблоны?

Останні версії делфі мають все чим колись гордились сішники — перегрузку операторів, шаблони і тд.

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

Язык мертвый -, но продолжает активно использоваться в СНГ.

Причм интересно что популярность имеет 7 версия выпущенная еще борландом

ru.wikipedia.org/wiki/CodeGear

7 мая 2008 года Borland и Embarcadero Technologies объявили о том, что Embarcadero «подписала соответствующий пакет соглашений по покупке CodeGear». Сделка, стоимость которой составляет примерно 24, 5 миллиона долл., завершилась 30 июня 2008 года.

COBOL разрабатывался специально для бизнес проектов

Разрабатывался, только большую часть приложений на COBOL заменили аналоги на VB, потом Java, потом.Net.

Кстати, 15 июня будет проводиться бесплатный семинар «Embarcadero: профессиональные инструменты разработки приложений и баз данных»

Если бы в сб, то может и сходил бы, для общего развития. Кстати, а что случилось с КодеЧеготаТам, которые выпускали Delphi после борланда?

Знакомый работает на COBOL! И че? Теперь все забиваем на Java/C# и учим COBOL?

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

Не совсем по теме, как именно роботает этот код? Или автор в ЕХЕ-шку вирус залил, как узнать?

Знакомый работает адвокатом. Все брысь в Могилянку получать второе ВО.

Вполне себе мейнстримные вещи делаются на Дельфи. Вообщем, изучать есть смысл.

Че все по новой? Не могли бы вы подтвердить свое имхо реальными фактами.

В банках используется Delphi!

Знакомый работает на COBOL! И че? Теперь все забиваем на Java/C# и учим COBOL?

В банках используется Delphi!

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

В банках используется Delphi!

Ознакомительная ссылка для Andrew, ну и другие могут посмотреть:

www.beremiz.org

maximus:

всё тот же Borland выпустил С++Builder. такая же IDE, только вместо object pascalя Сшный код. вот и используйте, кому нравится IDE. ещё и еxe’шник в 2 раза меньше., а паскаль удобен для изучения программирования с нуля

object-pascal / C++ / Object-C / C# / Жаба и пр. — это IMHO в данном вопросе не важно.
Основная ниша Delphi (а не object-pascal) была RAD? т.е. Rapid Application Development с уклоном в создание клиентов для БД.
Это и был основной козырь Delphi.
В этой нише не так важно насколько оптимально-переоптимальным будет ваш код. Оптимизация в Delphi никогда не дотягивала до штатных C++ компиляторов. Ответ прост: для написания «морды» или клиента это не особо нужно.
Зато Delphi позволял быстро и в предельно сжатые сроки создавать вполне функциональные внутрикорпоративы и даже очень неплохие коммерческие приложения без необходимости вылезать за рамки данной среды.
Но проблема в том, что именно в этой его целевой нише он и отстал последнее время от Жабы и C#. Причем, отстал существенно.
Пока Дельфи «болтался как дер... в проруби», поезд уже ушел существенно далеко.
Все же его весьма сомнительные «преимущества» как то компиляция сразу в x86, ассемблерные вставки, отсутствие необходимости фрэймворка и т.п. по нынешним временам в этой нише ни стоят ровным счетом ничего.
Помянем же, господа, хорошую в прошлом RAD среду программирования Delphi, существенно повлиявшую на развитие всей IT-индустрии, особенно на территории постсоветского пространства.
Да будет ей старая пылящаяся коробка с CD диском — пухом!

А сами же двинемся дальше не оглядываясь на прошлое:)

Сшный код. вот и используйте, кому нравится IDE. ещё и еxe’шник в 2 раза меньше

Билдеровский компилятор сосал еще у тогдашнего gcc, а сейчас тем более. Плюс практическое отсутствие готовых компонентов, нежно любимых б-кодерами и программистами-любителями.

всё тот же Borland выпустил С++Builder. такая же IDE, только вместо object pascal

я С

шный код. вот и используйте, кому нравится IDE. ещё и еxe’шник в 2 раза меньше., а паскаль удобен для изучения программирования с нуля.

Andrew:

Я там вказав, як я працюю з портами вводу виводу
Це дуже просто, так як завжди було у всіх версіях Делфі і на асемблері
in al, 123

Раніше не знав, що можна через CreateFile ()

Andrew, в серьезном проекте я бы за
asm... in al, 123... end;
руки бы пообрывал.
Такой код можно вставлять только в узкоспециализированный контроллер, а точнее в драйвер.
Но в написании драйверов вам Delphi не помошник. Там нужен С++
Мне вообще интересно, каким макаром это может быть выполнено под Win32 без привилегий ядра?!
Вы что каждому приложению будете давать привилегию ядра?!
А CreateFile () вы вызовете и из C# с таким же успехом.
Короче, Andrew решил козырнуть одним из последних “преимуществ” (именно в кавычках) Дельфи — встроенным ассемблером.
Мне лично этот встроенный ассемблер не понадобился ни разу за почти десятилетнюю практику на Делфи (хотя я и знаю ассемблер).
Но если уж необходимо писать такой высокооптимизированный код да еще и с ассемблерными вставками, то тут Делфи тоже не выбор.
Большинство C++ компиляторов справятся с этим ГОРАЗДО лучше.
Настолько лучше, что, возможно, и надобность в мало-понятном ассемблере отпадет (тем более, что возможность встроенного ассемблера есть и там)

А что же касается оптимизации самого языка, то конечный вариант уже x86 ассемблерного кода (не MSIL) cгенерированного из С# программы не хуже, а то и лучше, чем Delphi. Мы когда переползали на C# ставили такие эксперименты и сравнивали конечный ассемблерный код и качество этого кода нас очень и очень удовлетворило.


А Java i C# — це для дітей, які в програмуванні нічого, крім малювання формочок не бачили:)

Особливо C# — це для особливо малих дітей, які не бачили, що сталось із програмістами, котрі присвятили свої кращі роки вивченню технологій Майкрософта.:)

Честно говоря, тоже так думал.пару-тройку лет тому назад, пока не пересел на C#:)
C# имеет более продуманную и более стройную систему классов, чем Delphi.
И как раз таки он сильнее и удобнее Delphi в классо-писательстве, а так же в создании бизнес-логики и внутреннего каркаса приложения.
А “малювання формочок” почти одинаково (со своими плюсами и минусами в сравнении с Дельфей)
Честно говоря, единственного, чего лично мне не хватает в “малювання формочок” на С# так это встроенного аналога TActionList
Так что, Andrew, чисто профессиональный совет тебе, тикай ты тоже с Дельфей пока еще не поздно.
Нет там уже ничего хорошего — новых идей нет, перспектив нет (даже x64 лишь в отдаленном проекте, если вообще будет), с WEB-ом проблемы, с мобильным сектором проблемы, третьи фирмы тоже уже развернули нос в сторону.NET,

В Дельфях одна гниль только и осталась

И ВУЗы, в которых это «преподают».

Гвоздь номер 2.

Ниша номер два — студенты, которым главное — побыстрее слепить лабу/курсач.

Из собственного опыта, на.Net для начинающего слепить что-то на завтра намного быстрее чем на Delphi, и синтаксис у С# — больше похож на Java:)

Ниша названа — АСУ ТП на небольших пост-совецкий заводах, где требуеться не высокая стоимость и не требуеться высокое качество разработки
Если других нет, то предлагаю начать заколачивать гроб

Ниша номер два — студенты, которым главное — побыстрее слепить лабу/курсач. И ВУЗы, в которых это «преподают».

Somebody close this thread! What is the reason to continue the flame?

Don’t you see that the author is Delphi-only guy? Leave him alone.

/| /|||||__||| Please don’t|
/ O O\__ feed|
/ \ the trolls|
/ \ \|
/ _ \ \ —
/|\____\ \||
/||||\____/||
/ \|_|_|/| __||
/ / \|____|||
/|| /|| —||||//|____ —|
* _||_|_|_|| \-/
*— _—\ _ \ //|
/ _ \\ _ //| /
* / \_ /-| —||

* ___ c_c_c_C/ \C_c_c_c____________


in al, 123
mov voltage, al
Будь-ласка аналогічний код С# в студію!

Я не шарю в С#, но для Java я очевидно напишу за часик в раслабленном режиме функцию на С, которая предоставит мне такой вот интерфейс:

int voltage = PortHelper.readFromPort(123);

Я не вижу в этом киллер фичи.

Вот вы Andrew утверждаете что вы пишеты в потры ввода/ вывода напрямую асм вставками,
как вас систма пропускает, програма на 3-м кольце и с незаполненой битовой картой ввода/вывода сразу «прибивается» системой (вин98 вроде не прибивает), или используеся какая-то еще «програма» котороя эти ограничения снимает, так извените это ж кривизна чистейшей воды, драйвера для того и существуют что б не напрямую к портам ввода/вывода обращатся, а вы говорите драйвер не нужен.

Короче надо закопать делфи и никому не показывать.

Ниша названа — АСУ ТП на небольших пост-совецкий заводах, где требуеться не высокая стоимость и не требуеться высокое качество разработки

Если других нет, то предлагаю начать заколачивать гроб

Якщо кому не встиг відповісти — звиняйте:)

Постараюсь продовжити в понеділок.


Ні junior_dev, проблема не в тому, що я не розказав Вам щось про драйвер.
Проблема в тому, що Делфі може працювати з портами вводу-виводу, а C# не може.
приведеный вами пример асемблерного кода не являеться фичей Delphi вы так же его можете скопилировать и подключить в С#, он умеет работать с UnManaged DLL если интерескак см примеры выше для Win API.

Visual Studio так же позволяет дебажить в x32 managed & unmanaged код одновремено, так что это возможно в C#

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

не требуеться высокое качество — дабы не обидеть собеседника взято из того что народ готов жить с мнимым реальным временем на продуктах которые не поддерживаються (WinXP уже не поддерживаеться МСом насколько я знаю).


Аргумент, он этого не умеет потому что я не знаю как, а вам не скажу что, конечно убойный и тут ничего не возразишь:), но зато хорошо характеризирует
junior_dev, я вже 4 рази сказав як я це роблю. Це дуже просто.
in al, 123
Драйвер тут взагалі ні при чому.
Це просто була відповідь на питання Доцента.
Драйвер цей я використовував тільки 1 раз в житті, коли теба було офіційно поставити програмно-апаратний комплекс замовнику, а ніхто не міг продати мені ліцензійної Windows98.
Тоді мені довелося поставити систему на WindowsXP, а там є додаткові обмеження на доступ до портів вводу-виводу. Їх просто треба відключити от і все

У всіх інших випадках я працював без ніякого драйвера. І знання драйвера не потрібно взагалі. Навіть якщо його використовувати. Він просто запускається і знімає обмеження, які є в WindowsXP Програма ніяк з ним не взаємодіє.

если у вас есть драйвер с интерфейсом в User mode — то его можно использовать в C# так же как вы его используете в Delphi, так как я не знаю вашего драйвера я вам не могу код привести...
Ні junior_dev, проблема не в тому, що я не розказав Вам щось про драйвер.

Проблема в тому, що Делфі може працювати з портами вводу-виводу, а C# не може.

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

Кста для тег кто видел сначала Си подобные языки, а потом паскаль (делфи) он тож кажется убогим?

to Andrew

мне интересно знать, что именно вам удобно сам паскаль, или делфовская иде?

просто мені і багатьом іншим на Delphi зручніше.

Не хочу вас огорчать, но не “багатьом”, а “декільком”. Из моих знакомых кто заканчивал ВУЗ в последние 4 года, только один человек работал на Delphi, и то через год перешел на другой язык.

Якщо є кращі — я хочу про них знати.

Для каких задач?
Для написания сайтов? Программирования железок (которые в большинстве своем не под виндой)? Сознание информационных систем?

Вы можете четко описать нишу Delphi?

вы хотите сказать что ваше АСУ строиться на этих уникальных особеностях Delphi?

Ні, просто мені і багатьом іншим на Delphi зручніше.
А особливості ці не унікальні, вони в тих чи інших комбінаціях присутні в інших трансляторах.
Просто Delphi — це конкретна комбінація яка мені зручна для певних задач.

Якщо є кращі — я хочу про них знати. Але без флейма.

и все остальные удобства других языков не стоят этого?

Якщо ці зручності є, і в конкретній задачі себе виправдовують, то треба юзати відповідно іншу мову, а не Delphi.

Я вже про це сказав вище.

Тільки схоже, що сі-шарпу він не допомагає, бо в цієї мови немає деяких можливостей, які є в Делфі:)

пока что единственым вашим аргументом был in place асемблер, но вы можете этот код редактировать в студии и подключить в шарп

если у вас есть драйвер с интерфейсом в User mode — то его можно использовать в C# так же как вы его используете в Delphi, так как я не знаю вашего драйвера я вам не могу год привести...,
но как сказано было выше откройте Dependency Walker и посмотрите вызовы фунций и библиотеки и вызовите их из шарпа как я приводил так же выше для АПИ Винды...

Аргумент, он этого не умеет потому что я не знаю как, а вам не скажу что, конечно убойный и тут ничего не возразишь:), но зато хорошо характеризирует

В апартный порт писать без Kernel mode driver в NT ядре нельзя, или вы и драйвер в Delphi написали?

Драйвер окремий.
Він не специфічний для АСУ і писати його не треба.
Тільки схоже, що сі-шарпу він не допомагає, бо в цієї мови немає деяких можливостей, які є в Делфі:)

Пропоную на цьому закінчити.

В апартный порт писать без Kernel mode driver в NT ядре нельзя, или вы и драйвер в Delphi написали?


Кряк для ХР є
І це нормально? Ліцензія забороняє вінду крякати, будь-яку частину. На крякнутому ядрі глючної ХР запустим АСУ — жесть!
Я не знаю яке тут визначення «крякання».

Якщо я заставляю систему давати мені доступ до моїх власних потрів вводу-виводу, то це не є порущенням ліцензії

А як там у Делфі-асма з ССЕ3?

Точно не пам’ятаю, але достатньо впевнений, що ССЕ2 присутнє.

Якщо чогось мало — можна на FPK переїхати, там повинно все бути

А з вирівнюванням в пам"яті? Усьо грає? Можна вручну то вказати? Бо буває треба деколи.
На Делфі мені таке було треба тільки раз.
Вирівняв руками.
Але я нікого не агітую юзати Делфі там де воно не підходить.

Конкретно в мене було дуже мало проблем з кодогенерацією, і я їх всіх пофіксав за допомогою перекомпіляції FPK.


support.microsoft.com/kb/115831 — вот вам пример:)
Якщо це було звертання до мене з приводу портів, то ця сторінка тут взагалі ні до чого.

Схоже що дехто з тих, хто намагаються вчити мене, як правильно писати АСУ, так і не зрозумів різниці між апаратними портами вводу-виводу і СОМ-портами:)


Кряк для ХР є

І це нормально? Ліцензія забороняє вінду крякати, будь-яку частину. На крякнутому ядрі глючної ХР запустим АСУ — жесть!

а зачем такой код использовать в C#?
вы хотите сказать что ваше АСУ строиться на этих уникальных особеностях Delphi? и все остальные удобства других языков не стоят этого?
с темже успехом я могу спросить, а как сделать на Delphi
public static IPayment GetPaymentObject (string className)
{
//Get the current assembly object
Assembly assembly = Assembly.GetExecutingAssembly ();
//Get the name of the assembly (this will include the public token and version number
AssemblyName assemblyName = assembly.GetName ();
//Use just the name concat to the class chosen to get the type of the object
Type t = assembly.GetType (assemblyName.Name + “.” + className);
//Create the object, cast it and return it to the caller
return (IPayment) Activator.CreateInstance (t);
}
blog.benhall.me.uk/...-with-c-20.html

ведь это более практичное в больших и сложных приложениях;) ведь к примеру можно построить АСУ так что бы добавляя новый девайс в систему без обновления основного кода:) не останавливая его в реальном времени

А як там у Делфі-асма з ССЕ3?

А з вирівнюванням в пам"яті? Усьо грає? Можна вручну то вказати? Бо буває треба деколи.

Таке хіба в 98-й вінді ще можна було писати. ХР пряме звернення до портів банить. Чи у вас є кряк на кернел?

Кряк для ХР є.


Код на Делфі — один рядок
in al, 123
Ты подтасовываешь: — по первых это не код на делфи (кто то тут сокрушался что ему тяжело учить два разных языка — с и java, а асемблер и паскаль это похожие языки?)
Це код на Делфі.
Кожен бажаючий може скопіпастати його в Делфі і скомпілювати.

Вбудований асемблер — одна із переваг Делфі, про що я вже казав багато раз.

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

Ну почалося...

Ото проблема- в змінну записати:)


in al, 123
mov voltage, al

Будь-ласка аналогічний код С# в студію!

support.microsoft.com/kb/115831 — вот вам пример:)

+1 к Доценту насчет asm кода в NT ядре


in al, 123

Таке хіба в 98-й вінді ще можна було писати. ХР пряме звернення до портів банить. Чи у вас є кряк на кернел?


Код на Делфі — один рядок

in al, 123

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


Таймер реализован не Delphi, а ОС это ОС определяет частоту таймера:) я также вам привел ссылку на Win API функцию которая этот таймер создает...

Я її не помітив

in al, 123
Раніше не знав, що можна через CreateFile ()
Это обьясняет многое:) спасибо
Пример очень простой:)

www.c-sharpcorner.com/...M/win32api.aspx

Я не помітив на цій сторінці пояснення, як працювати з апаратними портами вводу- виводу через CreateFile ()
Сформулюю питання ще раз.
Мені треба зачитати байт з порта № 123
Код на Делфі — один рядок
in al, 123

Будь-ласка код на С#?

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


І взалалі — очевидно що в будь-якому разі, обробник таймера на Делфі буде відпрацьовувати швидше, ніж на C#.
не очевидно

Таймер реализован не Delphi, а ОС это ОС определяет частоту таймера:) я также вам привел ссылку на Win API функцию которая этот таймер создает...

Я там вказав, як я працюю з портами вводу виводу
Це дуже просто, так як завжди було у всіх версіях Делфі і на асемблері
in al, 123
Раніше не знав, що можна через CreateFile ()
Это обьясняет многое:) спасибо
Пример очень простой:)

www.c-sharpcorner.com/...M/win32api.aspx


А можна деталі?

Особливо про технології і іїхні конкретні переваги перед Делфі?

Я тебе уже приводил пример SAP MES, такая же архитектура скажем и у HP-шной MES — Java на центральном сервере и C/C++ на контролиурющих девайсах.
Преимущества? Да это просто на порядки более развитая платформа. Если мне нужно заюзать balanced tree, я это сделаю, а не буду копаться в исходниках pfk в поисках написанной студентом лабы непонятно как работающей, если ко мне прийдет начальство и скажет дописать фронт энд на web/flex whatever, я это сделаю, потому что платформа готова к этому, если мне нужна будет настоящая real time, я ее смогу добиться, и не буду прыгать с бубном вокруг сервера уповая на то что при серьезных нагрузках нужная страница памяти не уйдет в свап, или core процессора не будет занято обдумывать, а не установить ли для винды апдейт.

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

Ваш аргумент почему Delphi лучше C# — таймер — который API функция винды и реализован в.Net Framework 2

Наскільки я пам’ятаю, в тих постах мова йшла про таймер, котрий базується на WM_TIMER.
Я вказав, що вони більше 10 Гц не потягнуть.
Є приклад, як C# обробляє таймер хоча б на 500 Гц?
І взалалі — очевидно що в будь-якому разі, обробник таймера на Делфі буде відпрацьовувати швидше, ніж на C#.
Я не доводжу, що на C# не можна нічого написати.

Просто констатую перевагу Делфі в конкретному випадку.

Порты — с которыми вы в Delphi скорее всего работаете через API CreateFile function что тоже есть в C#

Я там вказав, як я працюю з портами вводу виводу
Це дуже просто, так як завжди було у всіх версіях Делфі і на асемблері
in al, 123
Раніше не знав, що можна через CreateFile ()

Можна приклад, як це робиться на C#?

вы готовы выкинуть поддержку, обновление, расширение, кучу приложений для эфективного и качесвеного кода итд... поэтому вопрос, неужели это ключевой момент в вашем АСУ?
Я нічого не викидаю.
Підтримка і все інше мені поки і не потрібно.
Для моїх задач і Делфі6 хватило би.
Хоча якщо б була потрібна підтримка, то напевно можна її купити, я просто ніколи не цікавився.
Ще раз — я нікого не агітую, що Делфі — це найкращий вибір взагалі.

Я просто показав конкретні переваги.

Если честно, это уже не смешно
Andrew, вас никто не принуждает бросать Delphi. Вам нравится синтаксис — это ваше право.
По поводу эффективность генерируемого машинного кода — мы не обладаем полной информацией. У вас есть четкие замеры что Delphi генерирует более эффективный код чем другие языки, если да то просьба «в студию», у меня нет обратной информации. Будет конкретика (реальные цифры) будем продолжать, до этого предлагаю, закрыть тему.
По поводу смерти Delphi:
Delphi — 2.715%
Статистику по предложения работы тут уже приводили.

На Delphi много написано, это надо поддерживать, поэтому еще некоторое время, какой-то спрос будет, но вот новые проекты мне не известны. АСУТП, о которых тут так много говорили, переписывать просто так никто не будет, поэтому они будут жить еще долго, но кучу всего на VB — тоже переписывать вряд ли будут, но это не делает VB «живым языком».


В принципі і звичайний масив можна розглядати як динамічний
array_typt=array [1...1000] of integer
P=^array_type
getMem (P...)
тільки треба щоб фактичний розмір був менший ніж оголошений, або відключати перевірку індекса
Це танці з бубном. А цілі числа довільної довжини і їх арифметика є з коробки в Делфі? Бо дивіться, як можна:
Type: h and hit Enter for context help.
[1] > (* 31297347234789239473987473497374934 934444444444444444444444444444444444874)
29245632249397500441803850234769243895666171601077244422937285837872388316
[2] >

Не згодиться вам таке в АСУ? Щоб про оверфлов не думати?


Є наприклад стандартний тип ТStrings, який дозволяє індексувати стрічками
Наскільки я пам’ятаю, в FPK є ціла бібліотека для хеш таблиць.
Якщо треба щось інше, то можна оголосити свій клас, перевизначити постфіксний оператор індексації []
І описати, що там треба.
Або перетворювати в стрічку. І індексувати нею, використовуючи використовувати TStrings
От бачите, скільки мороки. І після цього ще говорять про Паскаль як наше всьо в структурах даних.

А Делфі 64-бітний код генерує? А для SPARC? Бо дрантивий лісп вже давно підтримує купу платформ і осей, а С/С++ тим більше.


если человек строит АСУ ТП на триках языка типа a [3, 7, 6] = 376 то это обьясняет многое в плане квалификации...
Можна взнати, що саме це пояснює?
До речі АСУТП тут взагалі ні до чого.
А тріків тут ніяких нема, це загальна формула обчислення офсета в масиві.
І судячи з того, як (зовсім неправильно) Ви її записали, вона Вам незрозуміла.

Ваш пост, 8я страница

Простий приклад
є тримірний масив a []
вираз a [3, 6, 7] може бути
1. оптимізований під час компіляції (тобто транслюється в щось типу a [367])
STL буде обчислювати вираз 3*100+6*10+7 в рантаймі, що буде повільніше
не понял, что будет медленее и зачем превращать его в число в 10ти значной системе?
Я мав на увазі, якщо розмір кожного виміру 10, то результуючий офсет буде 367.
Ваш аргумент почему Delphi лучше C# — таймер — который API функция винды и реализован в.Net Framework 2
Порты — с которыми вы в Delphi скорее всего работаете через API CreateFile function что тоже есть в C#
и так же трик с масивом и получения офсета в нем...

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

на самом деле вам привели кучу примеров, просто вы их проигнорировали,

Я старався уважно читати все, що тут писали, але не помітив ні одного прикладу АСУТП на С#

кстати я знаю как минимум 3 завода с АСУ построеным на приведеных выше технологиях,

А можна деталі?

Особливо про технології і іїхні конкретні переваги перед Делфі?

но это бесполезно,

Напевно у зв’язку з відсутністю змістовних аргументів.

если человек строит АСУ ТП на триках языка типа a [3, 7, 6] = 376 то это обьясняет многое в плане квалификации...
Можна взнати, що саме це пояснює?
До речі АСУТП тут взагалі ні до чого.
А тріків тут ніяких нема, це загальна формула обчислення офсета в масиві.

І судячи з того, як (зовсім неправильно) Ви її записали, вона Вам незрозуміла.

на заре своей работы я писал АСУ ТП для 3х заводов

На С#?

, и помню что bottleneck там не в тех триках которые вы приводите...

Я ніде не казав, що bottleneck кожного АСУ ТП обов’язково в перформансі.

Я просто приводив конкретні переваги Delphi перед C#.

вы знаете что такое профайлер?

Ви мене спалили:)

Пішов на Вікіпедію, узнавати, що таке профайлер...

на самом деле вам привели кучу примеров, просто вы их проигнорировали, вполне возможно что из-за квалификации что лишний раз подтверждает что возможно вам это и дает несколько комфортные условия, но ограничивает в развитии, кстати я знаю как минимум 3 завода с АСУ построеным на приведеных выше технологиях, но это бесполезно, как бесполезно обьяснять зачем синхронизировать потоки в много поточном приложении, человеку который говорит что и так работает...
если человек строит АСУ ТП на триках языка типа a [3, 7, 6] = 376 то это обьясняет многое в плане квалификации... может вы и Length (string) заменяете на string [0] потому что так быстрее?

кстати, пресловутый перформанс Delphi в ваших примерах... на заре своей работы я писал АСУ ТП для 3х заводов, и помню что bottleneck там не в тех триках которые вы приводите... вы знаете что такое профайлер? вы хоть раз смотрели план выполнения?

але тут я наскільки розумію з ПК робиться промисловий комп"ютер, на яке вішається все — робота з фізичною апаратрою і бізнес логіка. Підхід досить специфічний. Я не зустрічав.

Може мої екскурси в програмування апаратури на Делфі створили враження, що я пропоную відмовитись від контролерів взагалі і все перевести на десктоп:)
Це не так.
Я просто пояснював, в чому конкретно є переваги Делфі перед С#
Хоча мені доводилось і керувати апаратурою прямо з десктопа.

В цьому теж інколи є свій зміст, особливо для швидкого прототипування.


Вбудовані хещ-таблиці та функції хешування:
Є наприклад стандартний тип ТStrings, який дозволяє індексувати стрічками
Наскільки я пам’ятаю, в FPK є ціла бібліотека для хеш таблиць.
Якщо треба щось інше, то можна оголосити свій клас, перевизначити постфіксний оператор індексації []
І описати, що там треба.
Або перетворювати в стрічку. І індексувати нею, використовуючи використовувати TStrings
Але я цим мало користувався.

Для динамічних структур даних мені було зручніше писати на перлі/пітоні.

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

Не дуже зрозумів, який “аналогічний” тип треба
Просто визначити ти масиву із змінним розміром наприклад

Type MyType=array of Inteher;

Покажіть мені таку структуру даних (масив з можливістю зміни розміру на льоту) в Паскалі. Як частину стандарту мови, а не лібу від дяді Миколи/Васі/Петі

А в чому власне проблема?
a: array of integer
setlength (a, 100)
В принципі і звичайний масив можна розглядати як динамічний
array_typt=array [1...1000] of integer
P=^array_type
getMem (P...)

тільки треба щоб фактичний розмір був менший ніж оголошений, або відключати перевірку індекса

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

Вбудовані хещ-таблиці та функції хешування:

www.cs.cmu.edu/...make-hash-table

Щоб не бути голослівним, от Вам лінк:

Покажіть мені таку структуру даних (масив з можливістю зміни розміру на льоту) в Паскалі. Як частину стандарту мови, а не лібу від дяді Миколи/Васі/Петі

2compdev
плюс пітсот
доречі порівняння досить влучне про конячку.

так і тут делфі бензину не просить і запряг і пашеш


Взагалі складно знайти мову з кращими структурами даних ніж Паскаль, або хоча б такими ж.
Ай, дайте спокій. Ви зовсім як вуйко з села, що все життя їздить на возі і нічого іншого знати не бажає. Віз простий, коням сіна дав і вйо:)
Ви хоч нікому цього не кажіть, засміють.

Після цього поста я зрозумів, що далі нема чого балакати — ми один одного не переконаєм. Тому успіхів Вам в розробці АСУ на Делфі!:)

Я думаю, Лісп має свої переваги перед Делфі для певних типів задач, хоча на цьому прикладі я їх не помітив.
Програма вже виглядає складнішою ніж делфійна і там ще пропущений місяць (є тільки рік)
Структури даних я зрівнював тільки з С
Звичайно є мови з кращими для деяких задач структурами даних (напрклад Python)
Але там по швидкодії і пам’яті різниця може бути в 100 раз і більше.
І переваги там тільки в деяких відношеннях.
Взагалі складно знайти мову з кращими структурами даних ніж Паскаль, або хоча б такими ж.
Єдина проблема — вони статичні.

Але там, де цього досить — проблеми нема.

А тепер дивіться, як ці приклади з роками пишуться без хардкоду і зайвих багів:


(defun print-data (data)
   (loop for year in (first data)
            for value in (second data) do
             (format t "Year: ~A Value: ~A~%" year value)))

Далі викликаєм: (print-data ’ ((2010 2011 2012) (33 55 22:)
і маєм:
Year: 2010 Value: 33
Year: 2011 Value: 55
Year: 2012 Value: 22
Ну як, на Ліспі це зручніше робити, чи на Делфі? І де більша гнучкість з вбудованими структурами даних?

Мій приклад теж дитячий, але надіюсь просвітить трохи.


Наприклад в АСУ Делфі здається в нас займає більшу нішу, ніж всі інші мови разом
Я ж кажу — підсіли люди в молодості, та й не годні зіскочити. А не боїтесь, що в компіляторі чи рантаймі бага якась вилізе? Хто вам на той делфі патч дасть? Сорсів-то нема, ага.
Ще раз — я не агітую за Делфі.
Я вказую на конкретний факт його домінування в певній ніші і пояснюю причини.

Якщо є кращі пропозиції — я хочу їх почути.

Я не вірю, що молодий випускник універу писатиме АСУ на Делфі.

При чому тут віра?
Я говорю про факти.
Я знаю небагато випускників, які пишуть АСУ, але вони всі пишуть на Делфі.

Може моя вибірка і нерепрезентативна, але все ж реальна.


Мені простосто ніколи не було треба — нагуглити готові бібліотеки для Делфі не проблема.
Та невже? Скажіть будь ласка, де я можу знайти бібліотеку для, припустимо, роботи з CAN? Досить типова шина для промислової електроніки.
Я з нею не працював, але перший лінк в гуглі -

http://www.vclcomponents.com/Delphi/Telephony___Communications/TCanDriver-info.html

САМ = ASM в попередньому порту

А ще є досить специфічні мови для ПЛК, тойже Степ5, наприклад

Та невже? Скажіть будь ласка, де я можу знайти бібліотеку для, припустимо, роботи з CAN? Досить типова шина для промислової електроніки.

Але я б сказав проблема не з самим каном шиною, так як для ПК вона не є природною.
Або через УАРТ\ЮСБ міст, або РСІ плату ставити.
біблотека іде із девайсом.
От уже з протоколами вищого рівня, наприклад, КАН-опен, то дійсно цікаво.
Я і на Сях шарпах мало що знаходив.
Не знаю, як дельфіни, але тут я наскільки розумію з ПК робиться промисовий комп"ютер, на яке вішеється все — робота з фізичною апаратрою і бізнес логіка. Підхід досить специфічний. Я не зустрічав.
АСУ ТП бачив і працював з тими, що зроблені власне для того ПЛК і т.п.
Бачив і працював з тими що зроблені ще на 68000 і 486. Писалось там все вперемішку С і САМ і особливих проблем не було.
Є досвід навіть з АСУ ТП на Бейсіку. Там БД, і звязок і апаратурою і подвійне резервуванні блоків.
Так що мій висновок такий, що комусь вдалося зробити такий патерн, як ПЛК на Делфі і діло отримало розвиток в певних колах.

До дельфіна буде питання, так як зара езернет і КАН шина де факто стають польовими шинами в апаратурі, як ралізується робота з ними на Делфі?


for year=2000 to 2010 do
for (year=2000; year < =2010; year ++)
Смотря на второй код очевидны начало цикла (2000), условие окончания (< =2010) и шаг (+1)
Прочитав паскаль код очевидно начало цикла (2000), но вопрос про окончание цикла (необходимо знать что он работает как < =2010, а не < 2010), необходимо знать что в for используется шаг=1 (хотя это не сложно угадать).
Згідний, що спочатку треба запам’ятати просте правило, в циклі for змінна проходить всі вказані значення включно (для більшості людей це напевно expected behaviour)

Але в моїй практиці проблеми з цим були в мільйон раз менші ніж з неправильним розіменуванням складних структур даних.

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

for (year=2000; year < 2010; year = log (year))

Треба буде писати циклом while
year: =2000; while year< 2010 do year: =log (year)
Але я мав на увазі не проблеми синтаксисом циклу, а проблеми з адресацією структур.
Мені доводиться додавати або віднімати 2000, що створює проблеми.
Є набагато більш незручні випадки.
Щось такого типу
Наприклад масив по місяцях і по категоріях
qty [12, ’A’] -яка кількість матеріалу категорії ’A’ була в 12 місяці.
В Паскалі, якщо я переплутаю індекси місцями, то компілятор це зловить ще під час компіляції.
А в С він і в рантаймі не зловить — щось там розіменує і все.
Якщо розрахунок складний, структура має 4 рівні вкладеності, а результат неочевидний (наприклад сильно зашумлені дані) то таку помилку можна шукати тиждень. (Замість 2 секунд на Паскалі)
Це звичайно залежить від складності конкретної задачі.

Якщо до двох вимірів, то напевно це не критично.


бо вже є купа розроблених АСУ
Яка така купа? А можна сайти виробників, умови підтримки, ціни? Чи то всьо на колінці клепається і далі одного заводу не виходить?
З тих що я знаю — в основному на коліні, хоча сайти в деяких є (хто фірми).

А умови напевно кращі ніж в конкурентів, раз вони тримають більшу долю ринку.


for (year=2000; year < =2010; year ++)
for (month=1; month< =12; month++)
printf («year= %i month=%i result=%i», year, month, res_fuc (a [year-2000, month-1]))
LOL
Спочатку міняєм змінну від 2000 до 2010, потім від неї 2000 віднімаєм... Так Ви бидлокодер маєте поганий стиль програмування?
Спеціально для тих, хто не здатний прочитати три рядки коду, додаткове роз’яснення:
Якщо змінну міняти від 0 до 10, то треба буде додавати при виводі року
printf («year= %i month=%i result=%i», year+2000, month, res_fuc (a [year, month-1]))
Тому при використанні нативних С-шних структур даних код буде в будь-якому випадку складніший і більш схильний до помилок.
Чим складніша структрура даних і логіка, тим більша ця проблема.
Звичайно її погано видно на такому простому прикладі, але схоже не те, що складність написання безпомилкових програм росте експоненціально від складності структури даних.

Відповідно є випадки, коли це створює проблеми аж до провалу проекту через зрив строків розробки.


Наприклад в АСУ Делфі здається в нас займає більшу нішу, ніж всі інші мови разом
Я ж кажу — підсіли люди в молодості, та й не годні зіскочити. А не боїтесь, що в компіляторі чи рантаймі бага якась вилізе? Хто вам на той делфі патч дасть? Сорсів-то нема, ага.

Я не вірю, що молодий випускник універу писатиме АСУ на Делфі.

Мені простосто ніколи не було треба — нагуглити готові бібліотеки для Делфі не проблема.

Та невже? Скажіть будь ласка, де я можу знайти бібліотеку для, припустимо, роботи з CAN? Досить типова шина для промислової електроніки.


В мене і на такий приклад часу особливо нема.
Він розрахований на того, хто хоче вникнути і зрозуміти суть.
Цей приклад просто показує, що на всякій мові можна писати неакуратно. Більше він нічого не показує.

Те що там можна −1 забути, чи ще щось таке, то мало що можна забути чи не знати. Ніби на Делфі нема поганого коду — теж тулять там все в button.click, забуваючи про нормальне проектування. Благо ІДЕ сприяє.


DCB структура оголошена, якщо не помиляюся, у stddef.h Ви можете використовувати цей хідер у Делфі?
А Ви про це...
Ні прямо stddef.h не використовую. Хоча напевно є якісь конвертори.
Мені простосто ніколи не було треба — нагуглити готові бібліотеки для Делфі не проблема.

І там як правило ще є приклади готових програм, то не треба розбиратись починаючи з нуля.


Дивлюсь я на цей код, і він мені не подобається. Прямо як лаба студентська, прости Господи
Дарованому коню в зуби не заглядають:)
В мене і на такий приклад часу особливо нема.
Він розрахований на того, хто хоче вникнути і зрозуміти суть.

Якщо бажання зрозуміти нема — ніякий приклад не поможе.

2Andrew

Вы привели очень интересный пример

for year=2000 to 2010 do

for( year=2000; year <=2010; year ++)

Смотря на второй код очевидны начало цикла (2000), условие окончания (<=2010) и шаг ( +1)
Прочитав паскаль код очевидно начало цикла (2000), но вопрос про окончание цикла (необходимо знать что он работает как <=2010, а не <2010), необходимо знать что в for используется шаг=1 (хотя это не сложно угадать).

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

for( year=2000; year < 2010; year = log(year))

?

Або автор вузько спеціалізувався в АСУ, і трохи не ту мову в юності обрав. Писати про переваги Паскаля і Делфі в цій області трохи маргінально, не той калібр в цих засобів.

Я не агітую за Делфі.
Просто коли тут почали розказувати, що Делфі ні до чого не годиться (без достатньо змістовних аргументів), я звернув увагу на те, що є багато задач, які написані на Делфі.
Наприклад в АСУ Делфі здається в нас займає більшу нішу, ніж всі інші мови разом.
Далі я виклав причини цього явища на мою думку.
Думаю, що моя думка обгрунтована і базується на досвіді в набагато більші мірі ніж абсолютна більшість протилежних постів.
Якщо в когось є ідеї кращих інструментів (бажано з реалізованими задачами), вони теж можуть викласти свою думку.
Мені було б цікаво взнати про кращі інструменти.
Поки що нічого такого не видно.
Про Java/C# я вже здається прокоментував достатньо- тут навіть не йде мова про якісь переваги над Делфі в даному класі задач. Тут ще взагалі під питанням, чи на них можна реалізувати АСУ.
Про С++ — в принципі показали що на деяких компіляторах формально досягається паритет з Делфі.
Але те, що на С++ можна написати АСУ — це не відкриття.
Питання в ефективності розробки.
На мою думку, Делфі ефективніше і по мірі ускладнення задачі відрив буде рости і ставати все більш помітним.
Причини я намагався пояснити — кращий синтаксис, функціональність роботи з помилками і кращі структури даних.

Напевно пояснення не дотягує до математичної теореми, але як вже вийшло.


Тобто ефективність мови програмування визначається ефективністю розробки коду, специфічного для конкретного АСУ, який не можна розробити окремо.
STL тут абсолютно нічим не допоможе.

Помоему это уже начался неадекватный бред. Откуда взялась идея разрабатывать код в риал тайме? Где это у вас так процесс построен?

Є критично важливі частини коду, які працюють з реальними механізмами, котрі рухаються в реальному часі.
Звичайно, вони проганяються наскільки можна без фізичного запуску завода.
Але раніше чи пізніше треба запустити з реальним запуском механізмів.
Не завжди вдається написати так, щоб все ідеально пішло з першого разу.
Пробні запуски дорогі і проблематичні, тому в типовому випадку треба наприклад запустити всю річну роботу за 3 пробних запуски. Я мовчу про ризики аварій при помилці в програмі і т.д.
Це саме складне в розробці. І ефективність розробки цих частин коду визначає ефективність всієї розробки в цілому.
Умовно
Є 90% звичайного коду (бізнес-логіка і взаємодія з користувачем) — це не проблема розробити.
9% — проста апаратура (тобто те, що можна від’эднати від заводу, запустити в тестовому режимі і відладити свій код без великих проблем)
1% — самий складний код реального часу, який бажано запустити з першого разу (хоча не завжди вдається)
От власне ефективність розробки цієї частини і є головним фактором.

Інші 99% можна розробити порівняно легко, хоча об’єм їх може бути і великий.

«Тобто ефективність мови програмування визначається ефективністю розробки коду, специфічного для конкретного АСУ, який не можна розробити окремо.» — это вообще метафизика какая то...

Я мав на увазі, що певні частини АСУ (неспецифічні для даного заводу) можна купити в готовому вигляді.
Наприклад цілу пакувальну машину з контроллером.
Або можна розробити окремо. Наприклад взяти дозатор в лабораторію, там насипати на нього піску і бавитись, поки все не запрацює. Після того можна готове рішення під’эднати в АСУ. Таку роботу також можна замовити сторонній фірмі.
Тут з ефективністю розробки як правило великих проблем нема.

А от специфічний для даного АСУ код, який не можна розробити окремо, це і є основна проблема.


\|||/
(o o)
,----ooO—(_)-------.
| Please      |
| don’t feed the  |
| TROLL’s !     |
’--------------Ooo—’
|__|__|
|| ||
ooO Ooo


Я в АСУ ні разу не зустрічався з потребою в такому класі, але думаю, що готові реалізації для Делфі існують.

Ну значит у тебя были очень плоские алгоритмы, но не нужно свой опыт экстраполировать на всю отрасль!

Я нічого не екстраполюю.
Алгоритми в мене бували всякі, але в критично важливих частинах АСУ вони дійсно прості. І це так і повинно бути.
Я просто пояснюю, що практичні переваги кращого синтаксису Делфі дають більше користі в моїх конкретних задачах, ніж гіпотетичні перваги STL.

Може в когось ситуація зворотня — нехай поділитиься.


Я как бы был одним из ее разработчиков, куда уж реальнее?...
Мене взагалі-то більше цікавить досвід впровадження.
Щось типу такого
є завод (бажано наш, а не закордонний)
Є два варіанти автоматизації
1. На основі Делфі
2. Інший
Спробували і є результати (час, бюджет, функціональність)
Чи там — подумали, порахували і от — оцінка.

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

Зрозуміло, що є понтові закордоні системи, які декларують багато інсталяцій десь там.
Але практика показує, що на це великої уваги звертати не треба.
При практичній перевірці на реальному нашому заводі вони можуть виявитися дуже неефективними.
Серия очень странных голословных утверждений.
Конкретну розкручену але неефективну АСУ-систему привести не можу, але практика схиляє до висновку, що ефективнісь розробки і впровадження не знаходится ні в якому співвідношенні ні з ціною, ні з кількстю задекларованих інсталяцій за кордоном.

Це не теоретичні гіпотези, а реальний досвід спілкування з різними продавцями всяких систем для заводів.

Охота Вам флудити. Всі ці розмірковування про STL мало чого варті, ящо ви тільки не майнтейнер gcc.

А сам STL зрештою не на елементи мови опирається? До них не зводиться? Які Ви знаєте взагалі методи оптимізації в компіляторах, окрім обчислення цих індексів школярських?

Той приклад з масивами взятий зі стелі. Чи Ви генерований код читали?

Приклад зі стелі. Він призначений для ілюстрації ідеї.
Ідея в тому, що звертання до статичного типу оптимізується компілятором легко.
Звертання до STL-генерованого типу — то є виклик функції користувача.
В деяких випадках він теоретично може бути в тій чи іншій мірі оптимізований, але це набагато складніше ніж оптимізація індексації статичного масиву.

Можна звичайно сподіватись на оптимізатор, але то не гарантований результат.

Я не бачу жодної причини казати що 3*100+6*10+7 піде в рантайм. І він таки не піде.

Можливо на даному конкретному прикладі і не піде, але взагалі швидкодія структур даних, описаних користувачем тільки в ідеальному випадку досягає швидкості нативних структур.

Як рішення проблеми пропонувався STL.
Але STL по функціональності не може повторити нативні типи

По якій функціональності? Чого бракує?

Я мав на увазі, що наприклад нативні масиви зі статичними індексами оптимізуюься компілятором тривіально.
Тобто коли я пишу а [2, 3, 7], цей код прямо повідомляє компілятору, що я зачитую масив, що спрощує оптимізацію.
А в при застосуванні STL потрібно буде проводити набагато складнішу оптимізацію виклику функцій користувача.

Чим складніша оптимізація потрібна, тим рідше і гірше вона буде спрацьовувати.


бо вже є купа розроблених АСУ

Яка така купа? А можна сайти виробників, умови підтримки, ціни? Чи то всьо на колінці клепається і далі одного заводу не виходить?


Я знаю багато прикладів обробки апаратури, написаних на Делфі.
В мене нема теоретичного доведення, що на Фокспро це неможливо.
Але це не є підставою писати АСУ на Фокспро.
Набагато логічніше йти перевіреним шляхом.

Мы ведь разговаривали про быстродействие и С#, а не проFoxPro и «обробку апаратури»?

Я взагалі-то говорив про швидкодію в контексті обробки апаратури.
Я не говорю, що Делфі- найкраще для всьго.
Мова йде про те, що є конкретні задачі, де Делфі краще ніж Java/C#/C++
І крім того Делфі- перевірений варіант, який точно підходить, бо вже є купа розроблених АСУ.

А зручність і ефективність C# для даного класу задач — це фантазія, поки нічим не підверджена.


for (year=2000; year < =2010; year ++)
for (month=1; month< =12; month++)
printf («year= %i month=%i result=%i», year, month, res_fuc (a [year-2000, month-1]))
LOL
Спочатку міняєм змінну від 2000 до 2010, потім від неї 2000 віднімаєм... Так Ви бидлокодер маєте поганий стиль програмування?

Це вже не до мови питання — таке городити. Це вже загальна здатність до проектування програм.


Ты не уловил суть моего аргумента, на современных серверах 300 мб — это 1% памяти, то есть они влияют на свопинг приблизительно так же как и 1 мб.

Тем более что цифра в 300 мб явно взята с потолка и не соответствует действительности.

1. Я якраз і мав на увазі що ці логічні побудови в практиці не завжди працюють, а тому перевірені варіанти є принципово кращими, ніж ті, які гіпотетично повинні би були працювати.
2. 300 МБ взяті не зі стелі, хоча цифра дійсно не має якогось точного змісту.
3. Сервери АСУ як правило не мають 30 ГБ пам’яті, і на те є серйозні причини.

Не треба плутати сарвер АСУ з іншими типами серверів. В нього інші задачі і конструкція як правило теж.

DCB структура оголошена, якщо не помиляюся, у stddef.h Ви можете використовувати цей хідер у Делфі?


Шановний! До чого тут calling conventions?
DCB — взагалі не функція. Це структура.
А оголошення функцій з різними calling conventions на Делфі робиться без ніяких пролем, аналогічно як і на С.
Весь WinApI так підключається.
В чому проблема?

Це було пояснення про

каждое обращение к ним из Паскаля требует дополнительных телодвижений

Тобто STL-ні структури даних працюють з такою ж швидкістю, як нативні?

Що ви розумієте під словом «нативні»? Ви хоч раз мали справу з STL?


структур данных, типа DCB из Паскаля и С
Не зрозумів, яких?
І що значить С-шный синтаксис?
Є просто зміщення конкретного поля в пам’яті.
Є така штука — calling conventions. Серед них є зокрема stdcall та pascal. Вам як любителю асемблерних вставок гріх таке не знати:)
en.wikipedia.org/...ing_conventions
Шановний! До чого тут calling conventions?
DCB — взагалі не функція. Це структура.
А оголошення функцій з різними calling conventions на Делфі робиться без ніяких пролем, аналогічно як і на С.
Весь WinApI так підключається.

В чому проблема?

Дивлюсь я на цей код, і він мені не подобається. Прямо як лаба студентська, прости Господи

З таким підходом до абстракцій у Вас всяка мова буде джерелом багів і проблем. Приклад не зараховується, надто криво написано.

Хлопче! Ти взагалі розумієш що таке STL?


Паскаль зможе це оптимізувати під час компіляції, а STL — ні.

Оптимізує компілятор, STL не має до цього ніякого стосунку.

Тобто STL-ні структури даних працюють з такою ж швидкістю, як нативні?


А в Делфі статичний конроль переповнення індексів був вбудований в транслятор ще з першої версії.
Ну да, ну да, только тебе там silverwolf уже привел пример когда статический контроль даже теоретически работать не будет.
Звичайно не завжди працює.
Але приємно, що хоч інколи допомагає.
Врешті, будь-яка технологія покращення ефективності програмування розв’язує не всі питання.

До речі — динамічний контроль індексів в Делфі теж набагато кращий ніж в С.

Я мав на увазі, якщо розмір кожного виміру 10, то результуючий офсет буде 367.
Паскаль може це розрахувати під час компіляції, а STL — ні (буде розраховувати в рантаймі).
А робота зі складними структурами без STL буде незручна.
Та і ще питання, наскільки буде зручно працювати з STL порівняно з Паскалівським стандартним синтаксисом.
А что тебя побудило сравнивать plain array и stl вообще?
Взагалі-то треба було зрівнювати більш складні структури, але було вже пізно і я спростив приклад.
Спробую придумати більш змістовний.
Але це непросто. Ці речі проявляються в складних проектах і дати простий приклад проблематично.

Наприклад є масив по роках і по місяцях.За десять останніх років і за всі місяці
на Паскалі це буде десь так a [2000...2010, 1...12]
наприклад код
for year=2000 to 2010 do
for month=1 to 12 do
write (’year=’, year, ’ month=’, month, ’ result=’, res_fuc (a [year, month]))
весь код буде простий і нема особливого місця для помилки
На С це буде якось так
for (year=2000; year < =2010; year ++)
for (month=1; month< =12; month++)
printf («year= %i month=%i result=%i», year, month, res_fuc (a [year-2000, month-1]))
1. над кодом треба думати більше ніж на Паскалі
2. вже є 3 потенціальних місця для помилки
year < =2010; — (’< =’ можна переплутати з ’< ’)
year-2000 — можна забути відняти константу. Крім того, в складніших випадках константу ще можна неправильно порахувати
month-1 — те ж саме
І ще одне погано в С — якщо помилка з індексом все-таки буде, то Паскаль її зловить зразу і навіть скаже де і в якому індексі, а С — ні

Стверджувалося, що проблеми можна вирішити за допомогою STL, от я і почав зрівнювати паскалівські нативні структури даних з STL


Тобто ефективність мови програмування визначається ефективністю розробки коду, специфічного для конкретного АСУ, який не можна розробити окремо.

Це називається Domain Specific Language (DSL). Паскаль і Делфі як засоби розробки DSL не катять, на то є Лісп.


Серия очень странных голословных утверждений

Це схоже на троллінг, правда не дуже прямолінійний. Або автор вузько спеціалізувався в АСУ, і трохи не ту мову в юності обрав. Писати про переваги Паскаля і Делфі в цій області трохи маргінально, не той калібр в цих засобів. Та й на лінух в разі чого не дуже розбіжишся портувати (чи зараз модно мати АСУ під Windows 7?) Якщо це справді українська реальність, то я в печалі©.

STL тут абсолютно нічим не допоможе
Хз, що тут допоможе. Дивні у Вас вимоги до функціоналу ліби.

А як у Вас з тестами? Чи ви прямо на конвеєрі баги лапаєте?

Я в АСУ ні разу не зустрічався з потребою в такому класі, але думаю, що готові реалізації для Делфі існують.

Ну значит у тебя были очень плоские алгоритмы, но не нужно свой опыт экстраполировать на всю отрасль!

2.Цей приклад взагалі не в тему.
Бібліотеку збалансованого дерева розробляти в ріалтаймі взагалі не треба.
Її можна спокійно розробити окремо і тільки підключити в робочий проект.
Критично важливими є помилки, які треба відлагоджувати в реальній роботі з апаратурою.
Одна така помилка може важити більше ніж 1000 звичайних, які можна спокійно виправити працюючи по своєму розкладу на окремому компі з відладчиком.
Тобто ефективність мови програмування визначається ефективністю розробки коду, специфічного для конкретного АСУ, який не можна розробити окремо.

STL тут абсолютно нічим не допоможе.

Помоему это уже начался неадекватный бред. Откуда взялась идея разрабатывать код в риал тайме? Где это у вас так процесс построен?

“Тобто ефективність мови програмування визначається ефективністю розробки коду, специфічного для конкретного АСУ, який не можна розробити окремо.” — это вообще метафизика какая то...


Думаю, що розробники однакового рівня будуть робити бульше помилок на С++ ніж на Делфі.
Та ну? Интересно сколько ошибок ты сделаешь в попытке реализвать сбалансированное дерево для класса:
Я на С++ ни одной, потому что оно уже реализовано!
1. Я в АСУ ні разу не зустрічався з потребою в такому класі, але думаю, що готові реалізації для Делфі існують.
2.Цей приклад взагалі не в тему.
Бібліотеку збалансованого дерева розробляти в ріалтаймі взагалі не треба.
Її можна спокійно розробити окремо і тільки підключити в робочий проект.
Критично важливими є помилки, які треба відлагоджувати в реальній роботі з апаратурою.
Одна така помилка може важити більше ніж 1000 звичайних, які можна спокійно виправити працюючи по своєму розкладу на окремому компі з відладчиком.
Тобто ефективність мови програмування визначається ефективністю розробки коду, специфічного для конкретного АСУ, який не можна розробити окремо.

STL тут абсолютно нічим не допоможе.

Я мав на увазі реальні особисті знання.

Я как бы был одним из ее разработчиков, куда уж реальнее?...

Зрозуміло, що є понтові закордоні системи, які декларують багато інсталяцій десь там.
Але практика показує, що на це великої уваги звертати не треба.

При практичній перевірці на реальному нашому заводі вони можуть виявитися дуже неефективними.

Серия очень странных голословных утверждений.


Як рішення проблеми пропонувався STL.
Але STL по функціональності не може повторити нативні типи.
Я показав один конкретний приклад.
Той приклад з масивами взятий зі стелі. Чи Ви генерований код читали?

Я не бачу жодної причини казати що 3*100+6*10+7 піде в рантайм. І він таки не піде.

Як рішення проблеми пропонувався STL.
Але STL по функціональності не може повторити нативні типи

По якій функціональності? Чого бракує?


Якщо в когось є ще дані — було б цікаво побачити.
Я тебе выше описал архитектуру SAP MES, у которой инсталяционная база — тысячи твоих заводов.
Я мав на увазі реальні особисті знання.
Зрозуміло, що є понтові закордоні системи, які декларують багато інсталяцій десь там.
Але практика показує, що на це великої уваги звертати не треба.

При практичній перевірці на реальному нашому заводі вони можуть виявитися дуже неефективними.


Не думаю.
Я знаю багато прикладів обробки апаратури, написаних на Делфі.
В мене нема теоретичного доведення, що на Фокспро це неможливо.
Але це не є підставою писати АСУ на Фокспро.

Набагато логічніше йти перевіреним шляхом.

Мы ведь разговаривали про быстродействие и С#, а не проFoxPro и “обробку апаратури”?


Теоретично, якщо я відкриваю локальний pdf-файл, то мій комп’ютер не бав би конектитись в майкрософт.
Але практично ситуація інколи буває інша.
Аналогічно, якщо в мене 1Г пам’яті і програма займає 300 МБ, то теоретично свопінга не повинно бути ніколи.
Але практика показує інше.

Тому всі складні фреймворки — то потенціальне джерело проблем, навіть якщо пам’яті ніби і повинно бути досить.

Ты не уловил суть моего аргумента, на современных серверах 300 мб — это 1% памяти, то есть они влияют на свопинг приблизительно так же как и 1 мб.

Тем более что цифра в 300 мб явно взята с потолка и не соответствует действительности.


Взагалі — те, що на C# можна написати код, співмірний по ефективності з Делфі, це ще як мінімум треба доводити.

Обратное тоже нужно доказывать

Не думаю.
Я знаю багато прикладів обробки апаратури, написаних на Делфі.
В мене нема теоретичного доведення, що на Фокспро це неможливо.
Але це не є підставою писати АСУ на Фокспро.

Набагато логічніше йти перевіреним шляхом.


Мова йшла про те, що паскалівські структури даних зручніші і швидші в розробці.
Як рішення проблеми пропонувався STL.
Але STL по функціональності не може повторити нативні типи.

Я показав один конкретний приклад.

А чем конкретно с-шный масив хуже в удобстве паскалевского в приведенном примере?


А якщо загружена якась джава/C#, то ситуація радикально інша.
Если у тебя современный сервер с памятью на пару десятков гиг, и система призвана обрабатывать соответствующие обьемы данных, то размер.net фреймворка не соизмерим с этими обьемами, и решающей роли не играет.
Теоретично це могло би бути так. Але практично алгоритми роботи вінди дуже дивні.
Теоретично, якщо я відкриваю локальний pdf-файл, то мій комп’ютер не бав би конектитись в майкрософт.
Але практично ситуація інколи буває інша.
Аналогічно, якщо в мене 1Г пам’яті і програма займає 300 МБ, то теоретично свопінга не повинно бути ніколи.
Але практика показує інше.

Тому всі складні фреймворки — то потенціальне джерело проблем, навіть якщо пам’яті ніби і повинно бути досить.


1. оптимізований під час компіляції (тобто транслюється в щось типу a [367])
STL буде обчислювати вираз 3*100+6*10+7 в рантаймі, що буде повільніше

Це залежить від компілятора. Такі наївні приклади оптимізуються всіма промисловими С++ компіляторами року десь так з 1998.

Ви згубили зміст розмови.

Мова йшла не про нативні структури даних, які звичайно оптимізуються в С (і напевно навіть краще ніж в Паскалі)

STL тут взагалі ні до чого.

Мова йшла про те, що паскалівські структури даних зручніші і швидші в розробці.
Як рішення проблеми пропонувався STL.
Але STL по функціональності не може повторити нативні типи.

Я показав один конкретний приклад.


Не зрозумів, яких?
І що значить С-шный синтаксис?
Є просто зміщення конкретного поля в пам’яті.
Є така штука — calling conventions. Серед них є зокрема stdcall та pascal. Вам як любителю асемблерних вставок гріх таке не знати:)

en.wikipedia.org/...ing_conventions


1. А не пытался ли уважаемый Andrew сравнивать вызовы API и заполнение системных структур данных, типа DCB из Паскаля и С?

Давно вже не працював з DCB, але наскільки пам’ятаю, ніяких проблем не було.

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

Є просто зміщення конкретного поля в пам’яті.

2. А не слыхал ли уважаемый Andrew, что пихать аппаратурозависимый код в ГУИ и бизнес-логику суть дурной тон?
1.Я про розробку АСУ знаю не зі слухів. Необгрунтовані твердження для мене не авторитет.
2. Бізнес- логіка тут ні до чого, я її поки ще взагалі ніде не згадував
А писати код обробки апаратури і GUI в одній програмі часто дуже корисно. Кожен розробник АСУ це підтвердить.
Крім того, якщо GUI заважає, то на Делфі без ніяких проблем пишуться і консольні програми і сервіси.

Але в моїі практиці їх була абсолютна меншість.

И что специально изобретена концепция драйвера, для обращения к любому физическому устройству через такую абстракцию, как файловый дескриптор?

Ця абстракція звичайно має свою область застосування.
Але не треба її тулити там, де вона погано підходить і радикально знижує ефективність розробки і екплуатації.
Умовно кажучи, такий драйвер — це АСУ, котре розроблено 1 раз і в ідентичному вигляді поставляється на мільйон заводів, в кожного з яких для його експлуатації використовується комп’ютер, на якому ще паралельно працюють секретарка і бухгалтер.

Абсолютна більшість АСУ мають інші параметри розробки і екплуатації.


Паскаль зможе це оптимізувати під час компіляції, а STL — ні.

Оптимізує компілятор, STL не має до цього ніякого стосунку. Її код доводили до пуття не першокласники, а якщо у Вас щось і впреться в обчислення індекса, то це не страшно. Зате для С++ є Intel C++ Compiler, а для Делфі яка таргет архітектура остання зараз?

А в Делфі статичний конроль переповнення індексів був вбудований в транслятор ще з першої версії.

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

Я мав на увазі, якщо розмір кожного виміру 10, то результуючий офсет буде 367.
Паскаль може це розрахувати під час компіляції, а STL — ні (буде розраховувати в рантаймі).
А робота зі складними структурами без STL буде незручна.

Та і ще питання, наскільки буде зручно працювати з STL порівняно з Паскалівським стандартним синтаксисом.

А что тебя побудило сравнивать plain array и stl вообще?


вираз a [3, 6, 7] може бути
1. оптимізований під час компіляції (тобто транслюється в щось типу a [367])
STL буде обчислювати вираз 3*100+6*10+7 в рантаймі, що буде повільніше

то есть паскаль таки умеет угадывать значение переменных времени выполнения?

Я в своєму прикладі навів не змінні, а константи (a [3, 6, 7])
При роботі із складними структурами часто виникає ситуація, коли деякі індекси фіксовані.

Паскаль зможе це оптимізувати під час компіляції, а STL — ні.


2. якщо якийсь індекс виходить за границі, це буде знайдено під час компіляції, а не під час падіння програми
STL такого не зможе
вы пробывали пользоваться системами code quality?

msdn.microsoft.com/...ibrary/bb429476 (VS.80).aspx

Не пробував — я не дотнеті не пишу.

А в Делфі статичний конроль переповнення індексів був вбудований в транслятор ще з першої версії.

Простий приклад
є тримірний масив a []
вираз a [3, 6, 7] може бути
1. оптимізований під час компіляції (тобто транслюється в щось типу a [367])
STL буде обчислювати вираз 3*100+6*10+7 в рантаймі, що буде повільніше
не понял, что будет медленее и зачем превращать его в число в 10ти значной системе?
Я мав на увазі, якщо розмір кожного виміру 10, то результуючий офсет буде 367.
Паскаль може це розрахувати під час компіляції, а STL — ні (буде розраховувати в рантаймі).
А робота зі складними структурами без STL буде незручна.

Та і ще питання, наскільки буде зручно працювати з STL порівняно з Паскалівським стандартним синтаксисом.


Думаю, що розробники однакового рівня будуть робити бульше помилок на С++ ніж на Делфі.
Та ну? Интересно сколько ошибок ты сделаешь в попытке реализвать сбалансированное дерево для класса:
class A {
public:
int a;
int b;
string c; };

Я на С++ ни одной, потому что оно уже реализовано!

Якщо в когось є ще дані — було б цікаво побачити.

Я тебе выше описал архитектуру SAP MES, у которой инсталяционная база — тысячи твоих заводов.

Взагалі — те, що на C# можна написати код, співмірний по ефективності з Делфі, це ще як мінімум треба доводити.

Обратное тоже нужно доказывать


2. Синтаксис С++ провокує більше помилок.
А тут простите? Это вопрос не языка, а профессионализма разработчика.
Не згідний.

Думаю, що розробники однакового рівня будуть робити бульше помилок на С++ ніж на Делфі.

3. Більшість людей в нас писали роботу з апаратурою на Делфі. Є більше інфи, прикладів, бібліотек, форумів.

Больше чем на C/C++? Не верю!© Кстати, одним «в нас» мир не ограничивается, есть еще «у них»:).

Моя особиста статистика така.
Я знайомий з 3 фірмами, які роблять АСУ і з двома заводами, які самі собі розробляють АСУ.
Всі три фірми пушуть на Делфі.
Один із заводів — на Делфі.
Другий завод — я точно не знаю, головний розробник емігрував вже давно, але здається в колишні часи писав на Делфі і С++, але віддава перевагу С++.

Якщо в когось є ще дані — було б цікаво побачити.

А якщо загружена якась джава/C#, то ситуація радикально інша.

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

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


Про фреймворки для C# я взагалі мовчу. Є напевно такі сервери АСУ, які запущені в роботу, коли ще і тих фреймворків не було.
вы наверное пропустили понятие билда в оптимальный код в момент деплоймента?
Пропустив:)
В Делфі код завжди оптимальний, тому це не потрібно:)
Взагалі — те, що на C# можна написати код, співмірний по ефективності з Делфі, це ще як мінімум треба доводити. При генерацію коду для колбеків і т.п. я вже написав.

Може і є якісь хаки, які дозволять по ефективності і функціональності наблизитись до Делфі, але для чого це, якщо можна писати на Делфі і не шукати собі проблем?

насчет
АСУ — це реальний час.
Я мав на увазі, що делфійна програма в 1М запускається наприклад за 0.03 сек.

разве это время соизмеримо с затратами первичного опроса всех устройств и установки соендинений? к чему это вам так важно?

Це важливо тому, що важливою проблемою є свопінг.
Простий обробник апаратного переривання, написаний на Делфі, може відпрацювати наприклад за 1 мікросекунду. Фактично затрати часу на стороні ОС на переключення контексту більші, ніж в самому обробнику (делфійному коді)
Але якщо під час обробки виник свопінг, то це вже як мінімум 10_000 мікросекунд, навіть якщо зі свопінга читається 1 кілобайт.
Так от — якщо делфійна програма займає 1М і більше нічого не загружено, то є практична гарантія, що свопінга не буде.
Крім того, при швидкодії читання з диска 100 МБайт/сек, зачитування навіть всієї програми з диска зайняло б 0.01 сек.

А якщо загружена якась джава/C#, то ситуація радикально інша.


Проблема в тому, що це треба реалізовувати.
Помилка в реалізації може коштувати дорого.
А на Делфі ця проблема не існує — я можу написати все в одній програмі, і синхронізувати різні програми просто не потрібно.

проблема реализовать правильно библиотеку?

Ще раз — питання не в принциповій можливості, а в ефективності.
А складних задачах кожен лишній рядок коду може стати проблемою

Якщо замість одної програми мені треба писати дві і відладити їхню взаємну роботу реальному часі — це сильно знижує ефективність розробки.


, а Делфі я можу оголосити, що певна адреса в моїй програмі — це те місце, де я хочу отримувати цей виклик таймера.
На цій адресі я можу зробити функцію в маш. коді, яку буде викликати система.
Якщо буде треба підняти швидкодію, я можу цю функцію написати повністю або частинно на асемблері.
Для цього мені не треба навіть переключатися в якесь інше вікно, а не те що писати окрему програму на С++.
это не фича Delphi, а операционой системы, и поэтому любая программа это может
msdn.microsoft.com/...ibrary/ms681985 (VS.85).aspx
или вы знаете как вызвать Win API из C#?
или вы думаете C# не имеет доступа к WinAPI или WM_*?
Наскільки я пам’ятаю, коли я працював з таймерами, то для задач вище 10 Гц треба було забути про WM_*
І взагалі, якщо б навіть і можна було на C# за допомогою якихось хаків згенерувати машинний код для колбека, і супер-оптимізуючим компілятором наблизити його по ефективності до Делфі, для чого це?
Якщо в Делфі це все вже є, давно було, працює гарантійно, не потребує ніяких спеціальних зусиль і часто навіть можна знайти готові програми, з яких можна стартувати.
Я ж не кажу, що це в принципі не можна написати на інших мовах (наприклад С++)

Питання в тому, що ефективніше в розробці і експлуатації.

А ще, якщо хочеться потужних вбудованих в мову структур даних, то велкам в світ Common Lisp. І для нього є безкоштовні компілятори (SBCL), які по швидкості коду не настільки відстають від С++, як можна спочатку подумати:

fprog.ru/...ns-on-steroids

Вчора було пізно, а постів багато, то я не помітив деяких питань:)

Постараюсь коротко відповсти сьогодні

Вам привели кучу вариантов... например я не уверен что на Boeing АСУ-ТП реализовано на Delphi;)

значит можно и без него и в более критических и высокоточных условиях пользоваться не Delphi

Звичайно можна, і для деяких випадків напевно і краще.
Просто по моєму досвіду, в більшості випадків Делфі набагато ефективніше ніж будь-які альтернативи.

І це не тільки мій досвід.

2. То есть вы хотите сказать что отображение хеш-таблиц, списков, структур в дебагере Delphi лучше чем в Visual Studio?

Ні, я такого ніде не казав.

Просто хеші в АСУ якось не дуже застосовуються. Тому ця перевага практично нічого не дає в даному класі задач

3. Кто вам мешает тоже самое сделать в Visual Studio? msdn.microsoft.com/...y/4ks26t93.aspx

Я завжди знав, що в деяких компіляторах С++ є хаки, котрі дозволяють наблизитися до Делфі:)
Правда так і не зібрався вияснити, наскільки добре вони реалізовані в кожному з цих компіляторів.
В Visual Studio вони здається навіть не поступаються Делфі.
Але тоді вже давайте так і скажем:

Делфі в цьому має суттєву перевагу перед С++, за винятком Visual Studio і, в деякі мірі, gcc.

4. Кто мешает подключить готовую библиотеку в C# проект в студии?

Я вже відповів десь на це питання.
Під час розробки АСУ нам як правило потрібно не тільки підключення готової бібліотеки, але і доробка.
Самий тривіальний приклад — бібліотека обробляє апаратне переривання від девайса.
Зміст переривання в нашому девайсі специфічний, тому процедура переривання повинна бути дописана.
На Делфі це просто з двох причин
1. Делфі генерує машинний код, тому можна написати обробник і передати його адресу куди треба.
C# не дасть мені адресу для колбека в машинному коді, не кажучи вже про швидкість його виконання.
2. Бібліотека для Делфі написана теж на Делфі, тому доробляти її нема проблем.
Якщо ж я пишу на C#, а бібліотека написана на чомусь іншому, то знання C# недостатньо для розробки.
Просто кажучи, програміст, який знає тільки Делфі, може написати АСУ
Програміст, який знає тільки C#, не може написати АСУ.

Крім того, всі рішення котрі передбачають декілька мов і виконання задачі одночасно декількома програмами, є менш надійними і ефективними, ніж монолітні.


1. оптимізований під час компіляції (тобто транслюється в щось типу a [367])
STL буде обчислювати вираз 3*100+6*10+7 в рантаймі, що буде повільніше
Це залежить від компілятора. Такі наївні приклади оптимізуються всіма промисловими С++ компіляторами року десь так з 1998. STL тут взагалі ні до чого. Хочете подивитись на сучасні техніки оптимізації, почитайте Алана+Кеннеді. Delphi 7 вже відстав, і не дожене.

А ще, компілятор краще брати опенсорсний, типу gcc — там при нагоді можна і багу якусь пофіксити, якщо вилізе, а не чекати, поки патч пришлють на 7 Гіг (патч більший, ніж сама система) для 2008 студії. Ну і коммьюніті вас не забуде:)

Интересный холиворчик, а я все пропустил. Поэтому для пара вопросов вдогонку.
1. А не пытался ли уважаемый Andrew сравнивать вызовы API и заполнение системных структур данных, типа DCB из Паскаля и С?
Просто там кагбэ С-шный синтаксис и каждое обращение к ним из Паскаля требует дополнительных телодвижений.
2. А не слыхал ли уважаемый Andrew, что пихать аппаратурозависимый код в ГУИ и бизнес-логику суть дурной тон?

И что специально изобретена концепция драйвера, для обращения к любому физическому устройству через такую абстракцию, как файловый дескриптор?

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

не похоже, иначе как это понять?

1. оптимізований під час компіляції (тобто транслюється в щось типу a [367])

STL буде обчислювати вираз 3*100+6*10+7 в рантаймі, що буде повільніше

или я что-то отстал от програмирования или в АСУ оно живет какой-то своей жизнью:)...

не понял, что будет медленее и зачем превращать его в число в 10ти значной системе?

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

2. якщо якийсь індекс виходить за границі, це буде знайдено під час компіляції, а не під час падіння програми

Че? Если у меня массив на 10 элементов, а я индекс прочитаю (например из файла) и он будет равен 157 (к примеру), то компилятор паскаля это отследит? Вы бредите.

є тримірний масив a []
вираз a [3, 6, 7] може бути
1. оптимізований під час компіляції (тобто транслюється в щось типу a [367])

STL буде обчислювати вираз 3*100+6*10+7 в рантаймі, що буде повільніше

то есть паскаль таки умеет угадывать значение переменных времени выполнения?

z = getZ();
x = getX();
c = getC();
a[z,x,c]

и компилятор угадает что вернут функции getZ, getX, getC? А потом оптимизирует доступ?


2. якщо якийсь індекс виходить за границі, це буде знайдено під час компіляції, а не під час падіння програми

STL такого не зможе

вы пробывали пользоваться системами code quality?

msdn.microsoft.com/...ibrary/bb429476 (VS.80).aspx

Простий приклад
є тримірний масив a []
вираз a [3, 6, 7] може бути
1. оптимізований під час компіляції (тобто транслюється в щось типу a [367])
STL буде обчислювати вираз 3*100+6*10+7 в рантаймі, що буде повільніше

не понял, что будет медленее и зачем превращать его в число в 10ти значной системе?


1. Кращі структури даних (все що складніше від одномірного масива і вказівника)

Че? Слова STL, Boost,.Net, JCF, Apache Commons, Colt — вам что-то говорят? У любого современного языка есть куча либ со структурами данных.

Звичайно є мови, де структури даних зручніші ніж в Паскалі (але не ефективніші)
Але в даному випадку про структури даних говорилося в контексті АСУ, асемблера, портів вводу-виводу і роботи з апаратурою.
Тому всі інтерпретовані мови викреслюєм зразу.
STL напевно може в деяких випадках допомогти, але думаю що в цілому це не замінить тих можливостей, які є в Паскалі.
Простий приклад
є тримірний масив a []
вираз a [3, 6, 7] може бути
1. оптимізований під час компіляції (тобто транслюється в щось типу a [367])
STL буде обчислювати вираз 3*100+6*10+7 в рантаймі, що буде повільніше
2. якщо якийсь індекс виходить за границі, це буде знайдено під час компіляції, а не під час падіння програми

STL такого не зможе

1. Кращі структури даних (все що складніше від одномірного масива і вказівника)

Че? Слова STL, Boost,.Net, JCF, Apache Commons, Colt — вам что-то говорят? У любого современного языка есть куча либ со структурами данных.

2. Синтаксис С++ провокує більше помилок.

А тут простите? Это вопрос не языка, а профессионализма разработчика.

3. Більшість людей в нас писали роботу з апаратурою на Делфі. Є більше інфи, прикладів, бібліотек, форумів.

Больше чем на C/C++? Не верю! © Кстати, одним “в нас” мир не ограничивается, есть еще “у них”:).


Не думаю, що в Джаві скоро з’явиться бібліотека для роботи з останніми:)

СОМ порт — это не апаратный порт ввода вывода?

Ні, СОМ порт (як фізичний пристрій) реалізується через декілька апаратних портів вводу виводу.
Конкретні значення і специфіка роботи може бути різна.

СОМ порт як логічний пристрій може бути і не зв’язаний з апаратними портами вводу-виводу взагалі (віртуальний СОМ порт)

Я просто заперечував проти того що Java/C# більш ефективні для даної конкретної задачі.

В данной ветке обсуждения ни о какой конкретной задаче речь не шла.

Я в основному говорив про задачі АСУ

Звучит как — я проверил на примере теорему большую Ферма — значит она правильная.

Напевно продуктивна аналогія, але не буду розвивати — пізно вже:)

Будь-яке АСУ — це реальний час. Тому що процес, яким вона керує, відбувається в реальному часі.
Это тоже в мемы! Я незнаю ни одной программы которая выполнялась бы в нереальном (фантастическом?)

времени.

В двох словах — є системи, де відклик має зміст відносно незалежно від часу.
Наприклад юзер жме кнопку і через 1 сек. формується фінансовий звіт.
Якщо цей звіт зформується через 100 сек, він не втрачає змісту.
АСУ — це реальний час.
Якщо матеріал дійде до заслонки через 2 сек., то команда на відкриття повинна бути раніше.

Якщо система розрахує параметри відкриття заслонки пізніше, ніж через 2 сек., то вже відбулася аварія, і ці параметри вже змісту не мають. Вони вже не відображають реальний стан системи і не несуть ніякої користі.

Всегда казалось, что главная фишка Delphi — это RAD, с упором на пользовательские интерфейсы. Для прототипирования — удобная среда. Внушает опасения уровень остальных продуктов Borland для организации процесса разработки: together, star team и т.д. Без хорошего инструментария начинать процесс разработки софта для промышленных масштабов я бы не рискнул.

К тому же, для АСУТП, существуют хорошие С++ фреймворки, например этот или этот.


1. Кращі структури даних (все що складніше від одномірного масива і вказівника)
2. Синтаксис С++ провокує більше помилок. Помилки в системах реального часу коштують дорого.

3. Більшість людей в нас писали роботу з апаратурою на Делфі. Є більше інфи, прикладів, бібліотек, форумів.

Рекомендую не много почитать про STL, Boost... наверное сила структур с шаблонами и shared_ptr & auto_ptr откроет вам новый мир;)

“может быть вы просто не умете их готовить” — из анекдота;)

Delphi — опишите ту нишу в которой он актуален. Если вы все-таки настаиваете на АСУТП — опишите преимущества перед C++.

1. Кращі структури даних (все що складніше від одномірного масива і вказівника)
2. Синтаксис С++ провокує більше помилок. Помилки в системах реального часу коштують дорого.

3. Більшість людей в нас писали роботу з апаратурою на Делфі. Є більше інфи, прикладів, бібліотек, форумів.


1. АСУТП
C++ + QT?
Моя суб’єктивна думка — розробка на Делфі швидша ніж на С++.
Чим складніші структури даних, тим більша різниця.

Крім того синтаксис асемблера зручніший.

2. Деякі задачі із складною логікою і/або не дуже простими структурами даних.

C++/Java/C#/будь-яка інша мова високого рівня?

Джава повільна.
В С++ складні структури даних реалізовані значно гірше ніж в Паскалі.

І взагалі синтаксис С++ провокує більше помилок.

3. Задачі, де треба невелику частину коду замінити на асемблер (на Делфі зручний синтаксис для того, щоб писати на асемблері прямо в коді)
Я не спецеаліст у системному програмуванні, але наскільки мені відомо — це погана практика. C/C++?
Я думаю, що це хороша практика.
Можна напевно і криво якось зробити, але в моїй практиці такого не було.
С дає хороший код, але в деяких випадках без асемблера не обійтись.

Крім того інколи важливо саме вставити асемблер в код, а не викликати якусь процедуру на асемблері.

4. Задачі де є готові бібіотеки/програми (наприклад керування певним девайсом)
C++/Java/C#/будь-яка інша мова високого рівня?
Я не проводив аналіз ринку.
Але більшість готових розробок, які я зустрічав, були на Делфі.
Не претендую на велику репрезентативність.
Java/C# — це в даному контексті взагалі не те.
Якщо в мене є бібліотека для Делфі, то вона і написана на Делфі.
Відповідно я беру її і дописую для себе.

Бібліотека для Джави (для роботи з девайсом) буде написана на С, тобто на Джаві я її дописувати не зможу взагалі.

P.S. Когда я просил список, то просил список конкретных задач, а не абстрактных. Из всего что вы перечислили только п1 — более-менее конкретный

Вже ніч, так що кокретизувати вже не буду:)


Здається дехто собі слабо уявляє різницю між СОМ-портами і апаратними портами вводу-виводу:).

Не думаю, що в Джаві скоро з’явиться бібліотека для роботи з останніми:)

СОМ порт — это не апаратный порт ввода вывода?

Я просто заперечував проти того що Java/C# більш ефективні для даної конкретної задачі.

В данной ветке обсуждения ни о какой конкретной задаче речь не шла.

Можу, це перевірено:)

Треба тільки правильно писати програми і конфігурити сервер:)

Звучит как — я проверил на примере теорему большую Ферма — значит она правильная.

Будь-яке АСУ — це реальний час. Тому що процес, яким вона керує, відбувається в реальному часі.

Это тоже в мемы! Я незнаю ни одной программы которая выполнялась бы в нереальном (фантастическом?) времени. Я тебе выше написал, что такое риал тайм система, и что винда ею не являеться.

Об’єктивний факт — не знаю ні одного АСУ на Джаві.

Я думаю что это специфика отечественного рынка, где на это в последние 20 лет были сравнительно небольшие бюджеты. Если делать все по взрослому, например если посмотреть на SAP MES, то это решение на джава, где process control написан на С, работает на спец. девайсах, и общаеться с java посредсвтом xml, а джава все складывает в oracle, реализует красивый web based UI, с красивыми графиками, окошками и т.д.

2Andrew
Давайте определимся с нишами (основными):
Java — корпоративные приложения, чаще всего серверные, обычно работаю без перезагрузки месяцами, поэтому задержка 0, 03 секунды против 1 секунды при перезагрузке не аргумент
C# — тоже самое, только под винду
C++ — системное программирование (в том числе и АСУТП)

Delphi — опишите ту нишу в которой он актуален. Если вы все-таки настаиваете на АСУТП — опишите преимущества перед C++.

FPK/Lazarus здається мають все що для цього треба.

C++ + QT? Кроме того, Lazarus — это официальный продукт (вроде был какой-то Kylix)? Насколько я знаю нет, значить его можно засунуть туда же куда и Mono.


Наприклад в джаві нема можливості працювати з апаратними портами вводу-виводу.
java.sun.com/...ducts/javacomm
Здається дехто собі слабо уявляє різницю між СОМ-портами і апаратними портами вводу-виводу:).

Не думаю, що в Джаві скоро з’явиться бібліотека для роботи з останніми:)

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

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

Нічого.

Я просто заперечував проти того що Java/C# більш ефективні для даної конкретної задачі.

Я можу на вінді виконувати певний код гарантовано раз в секунду.
В чому проблема?

Гарантировано — не можешь

Можу, це перевірено:)

Треба тільки правильно писати програми і конфігурити сервер:)

Покажіть мені хоча б один приклад АСУ, яке не є системою реального часу.
Я не могу тебе показать, но любая делфи АСУ — не риалтайм; -)

Будь-яке АСУ — це реальний час. Тому що процес, яким вона керує, відбувається в реальному часі.


Наприклад в джаві нема можливості працювати з апаратними портами вводу-виводу.

А как Delphi работает с этими портами на Linux, MacOS, *BSD...?

Я сам не писав під Linux, і *BSD, але здається там теж без проблем.
FPK/Lazarus здається мають все що для цього треба.

Але звичайно якщо проект юзає іншу функціональність віндовса, то можуть бути певні ускладнення.


Tому що розробка АСУ на Делфі швидша і зручніша ніж на Джаві (причини я вказав вище)
Крім того делфійна програма займає набагато менше пам’яті і швидше виконується, що важливо для роботи з апаратурою.

Об’єктивний факт — не знаю ні одного АСУ на Джаві.

Потому что наверное ты работаешь с отечественными АСУ.

Кстати, а как АСУ по английски? MES?


тільки ефективність розробки і експлуатації мабуть буде не дуже.

почему? байты становяться другими?

Тому що розробка АСУ на Делфі швидша і зручніша ніж на Джаві (причини я вказав вище)
Крім того делфійна програма займає набагато менше пам’яті і швидше виконується, що важливо для роботи з апаратурою.

Об’єктивний факт — не знаю ні одного АСУ на Джаві.


на Делфі це буде виглядати приблизно так
asm
in ax, 123
add ax, 67
out 87, ax
mov voltage, ax

end

Срочно в мемы; -)


Для этого есть понятие состояния, хранение которого и идентификация выноситься из библиотеки — я думаю абстракция хендла в Win API вам знакома, так что не вижу инжинерных проблем тут
Проблема в тому, що це треба реалізовувати.
Помилка в реалізації може коштувати дорого.
А на Делфі ця проблема не існує — я можу написати все в одній програмі, і синхронізувати різні програми просто не потрібно.
проблема реализовать правильно библиотеку?
не говоря уже о вашей маньяности к скорости доступа то если библиотека уже загружена в память то экономиться и место и время;) ,

а как кто-то сказал

АСУ — це реальний час.

это даже плюс


1. Делфі може працювати з апаратурою, асемблером, обробляти таймер і т.д., чого банально не можуть інтерпретовані мови.
почему? или вы думаете C# не имеет доступа к WinAPI или WM_*?

или делфи имеет какое-то другое ядро которое реализует эту функциальность?

Простий уявний приклад
мені треба зчитати значення з порта вводу-виводу № 123, додати 67 і записати в порт 87 і значеня зберегти в змінну voltage

на Делфі це буде виглядати приблизно так


asm
  in ax,123
  add ax, 67
  out 87, ax
  mov voltage,ax
end

Хотів би я бачити, як це буде виглядати на C#

Про обробку апаратних таймерів на інтерпретованих мовах — цікаво було б порівняти наприклад обробку мультимедійних таймерів на Делфі і C#, правда в мене вже натхнення закінчується:)


а Делфі я можу оголосити, що певна адреса в моїй програмі — це те місце, де я хочу отримувати цей виклик таймера.
На цій адресі я можу зробити функцію в маш. коді, яку буде викликати система.
Якщо буде треба підняти швидкодію, я можу цю функцію написати повністю або частинно на асемблері.

Для цього мені не треба навіть переключатися в якесь інше вікно, а не те що писати окрему програму на С++.

это не фича Delphi, а операционой системы, и поэтому любая программа это может
msdn.microsoft.com/...ibrary/ms681985 (VS.85).aspx

или вы знаете как вызвать Win API из C#?

Я мав на увазі, що делфійна програма в 1М запускається наприклад за 0.03 сек.
А джавішна, навіть 1К, запускається наприклад за 1 сек бо вона піднімає ще цілу джаву.

Про фреймворки для C# я взагалі мовчу. Є напевно такі сервери АСУ, які запущені в роботу, коли ще і тих фреймворків не було.

вы наверное пропустили понятие билда в оптимальный код в момент деплоймента?

насчет

АСУ — це реальний час.
Я мав на увазі, що делфійна програма в 1М запускається наприклад за 0.03 сек.

разве это время соизмеримо с затратами первичного опроса всех устройств и установки соендинений? к чему это вам так важно?


Я можу на вінді виконувати певний код гарантовано раз в секунду.

В чому проблема?

Реальний час спокійно реалізується User Mode.
І взагалі в чому проблема з User Mode?
почитайте:
en.wikipedia.org/..._Procedure_Call

так вот DPC особено в XP которую вы привели ввиде примера позволяет, какому-то девайсу зависнуть на неограничено долгое время и положить ваши User mode applications и тогда вы каждую секунду не увидите...

1. АСУТП
2. Деякі задачі із складною логікою і/або не дуже простими структурами даних.
3. Задачі, де треба невелику частину коду замінити на асемблер (на Делфі зручний синтаксис для того, щоб писати на асемблері прямо в коді)
4. Задачі де є готові бібіотеки/програми (наприклад керування певним девайсом)
1. Вам привели кучу вариантов... например я не уверен что на Boeing АСУ-ТП реализовано на Delphi;) значит можно и без него и в более критических и высокоточных условиях пользоваться не Delphi
2. То есть вы хотите сказать что отображение хеш-таблиц, списков, структур в дебагере Delphi лучше чем в Visual Studio? например как вам возможность задать специальное debug view для сложных структур чято бы сразу обращать внимание на ключевые моменты с больших наборах данных
3. Кто вам мешает тоже самое сделать в Visual Studio? msdn.microsoft.com/...y/4ks26t93.aspx

4. Кто мешает подключить готовую библиотеку в C# проект в студии?


Для этого есть понятие состояния, хранение которого и идентификация выноситься из библиотеки — я думаю абстракция хендла в Win API вам знакома, так что не вижу инжинерных проблем тут
Проблема в тому, що це треба реалізовувати.
Помилка в реалізації може коштувати дорого.

А на Делфі ця проблема не існує — я можу написати все в одній програмі, і синхронізувати різні програми просто не потрібно.

І взагалі — я не дуже собі уявляю, як наприклад ця програма на джаві буде обробляти таймер в 1 КГц.
таймер контролируеться ОС — Делфи тут не причем
На Делфі я можу оголосити, що певна адреса в моїй програмі — це те місце, де я хочу отримувати цей виклик таймера.
На цій адресі я можу зробити функцію в маш. коді, яку буде викликати система.
Якщо буде треба підняти швидкодію, я можу цю функцію написати повністю або частинно на асемблері.

Для цього мені не треба навіть переключатися в якесь інше вікно, а не те що писати окрему програму на С++.

Наприклад делфійна програма може бути розміром в 1М, а джаву запустити — це зовсім інші масштаби.
програма на C# может быть 100 килобайт так как Framework идет с виндой...
АСУ — це реальний час.
Я мав на увазі, що делфійна програма в 1М запускається наприклад за 0.03 сек.
А джавішна, навіть 1К, запускається наприклад за 1 сек бо вона піднімає ще цілу джаву.
Про фреймворки для C# я взагалі мовчу. Є напевно такі сервери АСУ, які запущені в роботу, коли ще і тих фреймворків не було.

Я опускаю питання пам’яті, свопінга і т.д.

1. АСУТП

Ну да, ее можно написать на делфи, если уже есть куча датчиков и контроллеров, на которых какой нибудь линукс или qnx крутиться; -)

1. АСУТП

C++ + QT?

2. Деякі задачі із складною логікою і/або не дуже простими структурами даних.

C++/Java/C#/будь-яка інша мова високого рівня?

3. Задачі, де треба невелику частину коду замінити на асемблер (на Делфі зручний синтаксис для того, щоб писати на асемблері прямо в коді)

Я не спецеаліст у системному програмуванні, але наскільки мені відомо — це погана практика. C/C++?

4. Задачі де є готові бібіотеки/програми (наприклад керування певним девайсом)

C++/Java/C#/будь-яка інша мова високого рівня?

P.S. Когда я просил список, то просил список конкретных задач, а не абстрактных. Из всего что вы перечислили только п1 — более-менее конкретный


Наприклад в джаві нема можливості працювати з апаратними портами вводу-виводу.
java.sun.com/...ducts/javacomm

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

Не треба намагатися робити все одним інструментом.
Почему?
Тому що є інструменти, заточені під конкретні задачі.
Нема інструменту, найкращого для всіх задач.

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

Я можу на вінді виконувати певний код гарантовано раз в секунду.
В чому проблема?

Гарантировано — не можешь

Правда, правда:)
Покажіть мені хоча б один приклад АСУ, яке не є системою реального часу.

Я не могу тебе показать, но любая делфи АСУ — не риалтайм; -)


А є такі типи задач, де нічого кращого ніж Делфі нема.

Список в студию!

Наприклад:
1. АСУТП
2. Деякі задачі із складною логікою і/або не дуже простими структурами даних.
3. Задачі, де треба невелику частину коду замінити на асемблер (на Делфі зручний синтаксис для того, щоб писати на асемблері прямо в коді)

4. Задачі де є готові бібіотеки/програми (наприклад керування певним девайсом)

Наприклад в джаві нема можливості працювати з апаратними портами вводу-виводу.

А как Delphi работает с этими портами на Linux, MacOS, *BSD...?


А в інших мовах нема того, що є на Делфі.
Например?

Наприклад в джаві нема можливості працювати з апаратними портами вводу-виводу.

Не треба намагатися робити все одним інструментом.
Почему?
Тому що є інструменти, заточені під конкретні задачі.

Нема інструменту, найкращого для всіх задач.

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

Я можу на вінді виконувати певний код гарантовано раз в секунду.

В чому проблема?

Будь-яка система АСУ — це система реального часу.
Это не правда.
Правда, правда:)

Покажіть мені хоча б один приклад АСУ, яке не є системою реального часу.

По теме — делфи лучше не учить конечно же.

Я би сказав, краще не обмежуватись ним:)

1. Делфі може працювати з апаратурою, асемблером, обробляти таймер і т.д., чого банально не можуть інтерпретовані мови.

почему? или вы думаете C# не имеет доступа к WinAPI или WM_*?

или делфи имеет какое-то другое ядро которое реализует эту функциальность? откройте Dependency Walker и посмотрите — Delphi использует Windows — и значит любая!!! Windows-програма потенциально это тоже может.

2. На Делфі написано напевно не менше половини наших АСУ, відповідно це не треба починати з нуля. Є всякі бібліотеки, форуми і т.д.

ну вот это аргумент, но опять же зависит от того какой уровень вы себе ставите, думаю на ВАЗе тоже есть море “уникальных” технологий которые вы не найдете на Toyota & BMW, но это не означает что они лучше:)

3. Напевно можна написати сервер бази даних на Джаві (не знаю тільки яка буде продуктивність), але сервер АСУ — то інше. В принципі написати напевно можна (разом з С++), тільки ефективність розробки і експлуатації мабуть буде не дуже.

почему? байты становяться другими? вы слашали что код компилиться в родную для процессора платформу — процессора где это выполняеться, а не собираеться как в случае Delphi, кстати как у Delphi 5 с подержкой Amd64? это к теме производительности


А є такі типи задач, де нічого кращого ніж Делфі нема.

Список в студию!

Лабораторная работа 1. Знакомство с Делфи.
Лабораторная работа 2. Рисуем в Делфи.
Лабораторная работа 3. Делфи и файлы.
Лабораторная работа 4. Делфи и базы данных.

Лабораторная работа 5. Вызов сторонних длл из Делфи.

в плане реальности времени Delphi это User Mode application со всеми от сюдого вытекающими...

Можна взнати з якими?

Під сервер АСУ береться виділена машина, де запускається тільки АСУ.

если вы хотите создать реальную систему реального времени то добро пожаловать в Kernel mode и там уж Delphi точно не живет:)

Реальний час спокійно реалізується User Mode.
І взагалі в чому проблема з User Mode?
Не треба тут розводити фантазії про злих марсіан, які відберіть в нас гарантований квант часу:)

Правильно написане АСУ на нормально сконфігурованому сервері працює як годинник.

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

имелось ввиду контекста Винды;)

Якщо ж ці функції викликаються через якусь dll-ку, то де гарантія, що вона не викликається одночасно з двох різних програм. Значить треба додатково писати код, який це фіксає. Його ще треба якось відладити і т.д.

Для этого есть понятие состояния, хранение которого и идентификация выноситься из библиотеки — я думаю абстракция хендла в Win API вам знакома, так что не вижу инжинерных проблем тут

Можна взнати чим?

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

Та я і не заперечую, що в плані працевлаштування Делфі — не кращий вибір

это был ответ не вплане даже трудоустройста, в ряде случаев делфи может быть выгоднее, это был ответ на ограничение вашего развития как специалиста... (4 мя странами и заводами наследия СССР)

І взагалі — я не дуже собі уявляю, як наприклад ця програма на джаві буде обробляти таймер в 1 КГц.

таймер контролируеться ОС — Делфи тут не причем

Наприклад делфійна програма може бути розміром в 1М, а джаву запустити — це зовсім інші масштаби.

програма на C# может быть 100 килобайт так как Framework идет с виндой...

А є такі типи задач, де нічого кращого ніж Делфі нема.

Список в студию!


2Andrew — имелось ввиду то что Делфи не дает никакого преимущества перед C#/Java в плане реальности времени на винде...высоко нагруженый сервер БД это тоже система реального времени then, и ничего, смогли же сделать на Java;)
1. Делфі може працювати з апаратурою, асемблером, обробляти таймер і т.д., чого банально не можуть інтерпретовані мови.
2. На Делфі написано напевно не менше половини наших АСУ, відповідно це не треба починати з нуля. Є всякі бібліотеки, форуми і т.д.
3. Напевно можна написати сервер бази даних на Джаві (не знаю тільки яка буде продуктивність), але сервер АСУ — то інше. В принципі написати напевно можна (разом з С++), тільки ефективність розробки і експлуатації мабуть буде не дуже.

Принаймі я не знаю ні одного АСУ на Джаві.


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

протокол взаимодействия библиотек в системе разработан давно и используя Делфи вы используете его тоже:)

Потрібен не протокол зв’язку абстрактних бібліотек, а протокол роботи з конкретними девайсами.

кто вам мешает использовать C++ библиотеку для кода который не воозможно написать на Java/C#

Кожен раз коли ми виділяєм певну функціональність в іншу бібліотеку, це створює додаткові проблеми.
Елементарний приклад — допустимо, я виконую декілька послідовних операцій з девайсом.
В монолітній програмі я маю гарантію, що ніяких інших операцій нема.
Якщо ж ці функції викликаються через якусь dll-ку, то де гарантія, що вона не викликається одночасно з двох різних програм. Значить треба додатково писати код, який це фіксає. Його ще треба якось відладити і т.д.
Масштаб цих проблем може недооцінюватися людьми, які не мають досвіду в таких розробках.
Уявіть собі, що програма наприклад 50_000 рядків, а пробні запуски заводу досить дорогі.
Отже є наприклад 3 пробних запуски, а потім починається сезон і завод працює 24 години на добу.

Так що треба цю програму запустити з чотирьох раз. І проходити відладчиком не вийде — пристрої на заводі пауз під відладчиком не роблять.

кстати, отдадка для этих продуктов куда приятнее чем для Делфи...

Можна взнати чим?

АСУ — це не 2000 форм написаних 30 індійцями, де треба за тиждень пофіксати роботу 10 форм, які і зараз ніхто не знає, як роблять.

особенно Делфи 5 которая замерла в развитии, а эти продукты активно улучшаються и обрастают...

Ці покращення спрямовані на свої типи задач. А є такі типи задач, де нічого кращого ніж Делфі нема.

проблема вы захотите работать на Западе, к примеру автоматизировать линию на заводе Мерседес... каковы ваши шансы там найти работу со знаниями Делфи?

Та я і не заперечую, що в плані працевлаштування Делфі — не кращий вибір

Думаю, що ефективність такого рішення буде набагато нижча, ніж на Делфі.
І ще невідомо, чи воно взагалі запрацює.

Делфи работает по тому же принципу, или выдумаете оно выностит Ядро ОС и ставит свое?

Я маю на увазі, що на Делфі можна просто написати все що треба.
А на джаві треба буде виносити частину логіки в окрему бібліотеку на С++, що ускладнює розробку.
Ускладнення можуть вийти набагато більші ніж були б в звичайній (не-АСУ) задачі.
І взагалі — я не дуже собі уявляю, як наприклад ця програма на джаві буде обробляти таймер в 1 КГц.
Далі можуть бути всякі технічні питання. Наприклад делфійна програма може бути розміром в 1М, а джаву запустити — це зовсім інші масштаби. Швидкодія і і т.д.
Та й знати 1 мову, яка може все, простіше, ніж 2 окремих.
Не кажучи вже про те, шо на Делфі такі речі писати легше ніж на С++.

Тому схоже що Java+CPP програє по всіх параметрах.

оно использет ряд системных библиотек для работы с устройствами, ряд своих библиотек и КОМ для предоставления более быстрого и легкого доступа...

в случае приведеном мной дизайн будет тот же, только обьекты будут другие:)...

Для звичайної десктопної задачі типу база даних/форма це б приблизно так і було.

Але для АСУ думаю, різниця може виявитися дуже великою.

А в інших мовах нема того, що є на Делфі.

Например?

Не треба намагатися робити все одним інструментом.

Почему?

Є бажання розвести холівар на тему визначення терміну “реальний час”?

Холивара быть не может, потому что есть вполне общепринятое условие риалтаймовости системы — это когда программист может создать условия, при которых гарантировано что какой то код выполниться не позже заданого момента времени. Винда — не риал тайм система, нагруженная база данных — тоже не обязательно риал тайм система, вообще нагрузка с риалтаймовостью слабо связаны. В тоже время на джава можно строить риал тайм системы, хоть это и не основной тренд сегодня: java.sun.com/...time/index.jsp

Будь-яка система АСУ — це система реального часу.

Это не правда.

По теме — делфи лучше не учить конечно же.

в плане реальности времени Delphi это User Mode application со всеми от сюдого вытекающими... если вы хотите создать реальную систему реального времени то добро пожаловать в Kernel mode и там уж Delphi точно не живет:) там вы познакомитесь с Asm/C & WinDbg...

поэтому by design, Delphi ничего не может такого особеного чего не могут другие User mode platforms и поэтому тут нет разницы C#/Java vs Delphi у Delphi Могут просто быть уже готовые компоненты на какие-то случаи жизни..., но даже это не беда, С# как детище МСа, прекрасно интегрируеться с COM.

2Andrew — имелось ввиду то что Делфи не дает никакого преимущества перед C#/Java в плане реальности времени на винде...высоко нагруженый сервер БД это тоже система реального времени then, и ничего, смогли же сделать на Java;)

Отлично, а с каких пор делфи на винде стало системой реального времени?...

Є бажання розвести холівар на тему визначення терміну «реальний час»?

Будь-яка система АСУ — це система реального часу.

где там ORM, web frameworks и CMS для делфи?

Я думаю зараз для веба краще на Делфі не писати.
Хоча знаю і такий приклад — ситема резервування авіабілетів для авіакомпанії:)
Дійсно на Делфі немає деяких речей. І мабуть нема змісту їх там доробляти.
А в інших мовах нема того, що є на Делфі.
Не треба намагатися робити все одним інструментом.
За останні 10 років придумали багато нових мов і вони мають свої області застосування.

А Делфі треба використовувати там, де це дає кращий результат, ніж інші мови.

+10 к теме реального времени в Винде...

А якщо вона ще буде складатися з двох частин, з’єднаних саморобним протоколом, який ще треба теж відладити, то пофіксати всі глюки може і не вдатися.
протокол взаимодействия библиотек в системе разработан давно и используя Делфи вы используете его тоже:) кто вам мешает использовать C++ библиотеку для кода который не воозможно написать на Java/C++

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

Не дуже зрозумів, в чому може бути проблема.

проблема вы захотите работать на Западе, к примеру автоматизировать линию на заводе Мерседес... каковы ваши шансы там найти работу со знаниями Делфи?
то есть вы себя по сути как специалиста замыкаете на тех странах и заводах которые готовы так работать... не уверен что современые компании тоже готовы работать с Делфи (например Кола-Кола в Украине)...,

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

Думаю, що ефективність такого рішення буде набагато нижча, ніж на Делфі.
І ще невідомо, чи воно взагалі запрацює.
Делфи работает по тому же принципу, или выдумаете оно выностит Ядро ОС и ставит свое? оно использет ряд системных библиотек для работы с устройствами, ряд своих библиотек и КОМ для предоставления более быстрого и легкого доступа...

в случае приведеном мной дизайн будет тот же, только обьекты будут другие:)...

АСУ — це система реального часу, яку відладити і так не просто.

Отлично, а с каких пор делфи на винде стало системой реального времени?...

Може в топіку народ і мав на увазі саме це, але в деяких постах стали доводити що Делфі — це неефективна технологія. А це вже зовсім інше твердження.

Делфи — отличная технология для толстых клиентов с Data Access в виде SQL, но так как мир активно движеться в сторону web и т.д., то делфи уже — да — неэфективна. Тем более что низкая полулярность являеться причиной слаборазвитой экосистемы: где там ORM, web frameworks и CMS для делфи? Где средства построения Continuous Integration, где средства мониторинга для высоконагруженных приложений? А все это есть из каробки на например абсолютно безплатных опен сорс стеках на джаве.

вы имеете ввиду АСУ украинских заводов,

українських, російських, білоруських і казахських

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

А в чому власне проблеми?
Обновлення особливо і не потрібні. Ще делфі 5 мало такий функціонал, що для більшості АСУ і зараз би було достатньо.
А ліцензія на WindowsXP — 70 доларів.

Для того щоб запускати делфійну програму, більше нічого не треба.

а вот если вы захотите автоматизировать к примеру завод на Западе (расширить свою область дальше родной Неньки) может получиться что Делфи не катит...

Не дуже зрозумів, в чому може бути проблема.

кстати, насколько я помню АСУТП то там сильные позиции у С/С++, а для них есть куча вариантов написать Гуй в тех же Жава/Шарп и связать с дравером написаном на С/С++
Думаю, що ефективність такого рішення буде набагато нижча, ніж на Делфі.
І ще невідомо, чи воно взагалі запрацює.
АСУ — це система реального часу, яку відладити і так не просто.
А якщо вона ще буде складатися з двох частин, з’єднаних саморобним протоколом, який ще треба теж відладити, то пофіксати всі глюки може і не вдатися.
Це ж не звичайна програма, де можна проходити відладчиком, зупинитися і подумати 5 хв, що тут не так.

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

вы имеете ввиду АСУ украинских заводов, которые в большинстве случаев ни о поддержке, обновлении и лицензионном соглашении не думают, ,
а вот если вы захотите автоматизировать к примеру завод на Западе (расширить свою область дальше родной Неньки) может получиться что Делфи не катит...

кстати, насколько я помню АСУТП то там сильные позиции у С/С++, а для них есть куча вариантов написать Гуй в тех же Жава/Шарп и связать с дравером написаном на С/С++

зная что-то низковостребованое вы ограничиваете свое развитие этой областью, если вам это нравиться и удобно это — ок,

1. Знати щось і обмежуватись цим — не одне і те ж.
2. Я не агітую за Делфі, і напевно погоджуся, що якщо хтось тільки починає вивчати програмування, планує просто заробляти гроші, то напевно Делфі — це не кращий вибір і ще невідомо чи ввійде в першу десятку.
Але для об’єктивності треба відмітити, що це можливо найсильніша на даний момент технологія в певних областях (наприклад в розробці АСУ для заводів), і там вона дуже потрібна і поки особливих трендів в напрямку зміни цього стану не видно.

Просто такі задачі рідко попадають в офшор, а офшор зараз в нас — головне джерело робочих місць.


можно продолжить...
на асемблере можно написать то что можно написать на Делфи,

но не все что можно на АСМе можно написать в Делфи... итд...

Не згідний.
Я не бачив ні одного випадку, щоб серйозну програму, написану на Делфі, хтось зміг переписати на Асемблері.

Затрати часу будуть неприпустимо великі. Тому це зробити практично неможливо (тобто вкластись в дедлайн і бюджет)

в топик народ имел ввиду мейнстрим и конкурентность на рынке разработчков... и постулат сводился к тому что благодаря поддержке разработчиков Ораклом и МС у последователей тех технологий больше шансов завтра найти проект и работу...

Може в топіку народ і мав на увазі саме це, але в деяких постах стали доводити що Делфі — це неефективна технологія. А це вже зовсім інше твердження.

зная что-то низковостребованое вы ограничиваете свое развитие этой областью, если вам это нравиться и удобно это — ок, ,

но если человек хочет добиться чего-то большего то нужно смотреть и на то что востребовано (проблема что лучше быть единственым програистом в мире на Коболе или одним из тысяч на Жаве... у каждого из аспектов есть свои +/-)

можно продолжить...
на асемблере можно написать то что можно написать на Делфи,
но не все что можно на АСМе можно написать в Делфи... итд...

в топик народ имел ввиду мейнстрим и конкурентность на рынке разработчков... и постулат сводился к тому что благодаря поддержке разработчиков Ораклом и МС у последователей тех технологий больше шансов завтра найти проект и работу...

Delphi — уже даже не RAD (потому как на Жабе и С# те же задачи реализуются быстрее),

“на Жабе и С# те же задачи” інколи не реалізуються ніяк:)
І зрівнювати Java і Delphi мабуть не зовсім коректно. Це в певному змісті різний калібр.
Все, що можна написати на Java, можна написати і на Delphi.
Навіть інтерпретатор Java можна написати на Delphi:)
Але не все, що можна написати на Delphi, можна написати на Java.
Приклад 1
Колись я написав програму, яка дозволяла мені провести аналіз даних на своїй локальній машині швидше, ніж на американському кластері, котрий складався з багатьох блейдів. Звичайно тут зіграла свою роль не тільки якість компілятора, але в першу чергу розуміння мікроархітектури процесора і т.д. Але в будь-якому разі в Java i C# шансів тут нема.
Приклад 2
Колись мені треба було написати драйвер саморобного девайса.
Я зробив це на Delphi десь за тиждень.
До того досвіду роботи з апаратурою під win32 не було взагалі.
Не знаю, скільки я б писав той драйвер на С# чи Java, але напевно дуже довго:)

Для багатьох програм, котрі потребують чогось більшого ніж база даних/візуальні форми, я і на даний момент не бачу чогось кращого, ніж Delphi.

, а все больше архаичное средство ООП для упертых старых перд...в, все еще страдающих ностальгией по TurboPascal-ю

А Java i C# — це для дітей, які в програмуванні нічого, крім малювання формочок не бачили:)

Особливо C# — це для особливо малих дітей, які не бачили, що сталось із програмістами, котрі присвятили свої кращі роки вивченню технологій Майкрософта.:)

Позволю себе высказать свое мнение. Дело скорее не в языке. На мой взгляд, здесь «Проблема роли личности в истории компании».
Всем известно, что Филипп Кан учился у Николаса Вирта, создателя языка Pascal, который позиционировался, как замена языку Basic для обучения студентов программированию. Филипп, имея собственноручно написанный компилятор, прикупил еще и компилятор Андерса Хейлсберга, к которому прикрутил редактор (или наоборот) и выпустил продукт Turbo Pascal. Сочетание в одном флаконе редактора, компилятора и отладчика (все это потом назвали IDE), плюс стоимость в 10 раз ниже, чем аналоги конкурентов, плюс дурацкая реклама, и т.д. привело к продаже 300 000 копий в течение 2 месяцев. Потом был арест федералами счетов компании, в которой числилось 2 человека, а потом очень много денег в карманах.
Вот этого, все и началось. Филипп стал крутым хлопцем. Он приглашет на баснословные барыши того же Андерса и его друга Нила Йенсена в свою компанию Borland International. Через четыре года Нил понимает, что Филипп не компиляторщик, потому как у Вирта уже есть Модула-2, а средств компания на ее разработку выделяет не достаточно, хлопает дверью и уходит. Все зачатки проведенных работ по ООП, через два года появляются в Turbo Pascal. Появляется новый язык Turbo Pascal. Borland продолжает быть на коне. Редактор, компилятор, отладчик, объектно-ориентированный язык и все это на одной дискетке. Это бомба. Язык, извините Продукт, набирает обороты. Все DOS наш на веки.
Огромную популярность, продукты Borland приобретают на постсоветском пространстве. Не имея Интернет, и хоть какой нибудь литературы, программисты СССР, отдают предпочтение Borland, из-за исходных кодов библиотек, которые поставлялись вместе с продуктом. Наши программисты учились программировать, читая чужие исходные тексты.
В это время, Microsoft помучилась со своим pascal, плюнула, и решила Windows переписать на Си, и потихоньку начала пропихивать ее в массы. Титанические усилия Билла, начинают приносить плоды. А крутой хлопец Филипп, все сорит деньгами на право и налево. Покупки компаний, завтраки за 650 тысяч, остров около Канн т.д., короче много скандалов. Одновременно, крысы аналитики с Wall Street, со всех голубых экранов спрашивают, когда же буде у Borland, что-то под Windows. Есть!!! Borland Pascal 7.0!!! Пишите дорогие в DOSе, программы для Windows. Правда, не все этот юмор оценили. Borland спохватывается, и выпускает Turbo pascal for Windows, обновляет несколько его версий и... затихает на 18 месяцев. Ни ку-ку ни гу-гу. А Microsoft тянет свой Visual C++, на котором сама и пишет, ну, а для любителей Visual Basic. Который тоже стал уже не языком, а продуктом. Хотя, надо отметить, в Visual Basic, появились компоненты, но как-то не совсем такие как хотелось, писать их надо было на Visual C++. Профессора, даже название придумали компонентно-ориентированное программирование.
Вот во время ни ку-ку ни гу-гу, в Borland происходят, какие-то терки, Филип, продает кому-то за 100 миллионов, акции, и дает по-рулить компанией, а сам наяривает на саксофоне. В итоге, на свет появляется Delphi, удобно, хорошо, красиво, быстро и самое главное компоненты можно писать в самом Delphi, с помощью VCL. Успех есть, но уже не тот. Тут до коршунов из Microsoft, доходит, что Delphi не Visual Basic, а гораздо серьезнее в нем есть VCL, и дело совсем не в языке, а в архитектуре библиотеки. Вот Microsoft взяла и купила «простого слесаря» Андерса, за большие коврижки, даже разрешили свой язык разработать С#. «Ну как же, Вирт уже в истории, и я хочу». Амибициозные эти люди — программисты.
За это время Нил, создал TopSpeed, уникальный продукт, аналогов ему я просто не знаю. Но программист, не менеджер. Продукт, не пошел.
К чему эта вся сказка?
За время своих внутренних непонятностей продукты Borland стали не business free. Бизнес, перестал доверять, компании, которая кинула на целых 18 месяцев разработчиков и соответственно их клиентов.
Поэтому и в Финляндии, и в Штатах и в других странах где есть рынок, где бизнес планируют и считают деньги не только сегодня, но и завтра, так мало Delphi.
А перечисленные, в первом посте, продукты, это в основном советские программисты и их последователи.
Морали наверное в этой сказки не будет.
Очень жалко, что никудышний менеджер, продудел в трубу, и свой гениальный IDE, и уникальные разработки коллег, и серьезные продукты других, купленных, компаний. Сорвало крышу у Филипа от много денег.

Вот такое мое IMHO.

На Российском рынке ситуация с Delphi может быть пока и не такая плачевная.
Но новых проектов почти не начинается.
Внутрикорпоративы тоже много где уже переезжают на Жабу и C#
Delphi — уже даже не RAD (потому как на Жабе и С# те же задачи реализуются быстрее), а все больше архаичное средство ООП для упертых старых перд...в, все еще страдающих ностальгией по TurboPascal-ю

Ну и поддержка старых проектов естественно.


Делаем поиск по Delphi на
monster.com
dice.com...

и видим реальную картину:)

Угу, делаем:
monster.com
Delphi

Россия — 0 предложений
Штаты — 99 предложений. Причем, часть из них относится не к Delphi программистам, а к медикам «Delphi Healthcare Partners»
c#
Россия — 2 предложения
Штаты — 3507
Комментарии излишни...

На Российском

Делаем поиск по Delphi на
monster.com
dice.com...

и видим реальную картину:)

Пока Delphi явно проигрывает эту гонку.
И MS со своим C#+.NET явно уходит в отрыв.
На текущий момент у Delphi (включая последний D2010) не осталось ни каких существенных преимуществ перед C#
Ровным счетом никаких!!!
Кроме разве что пресловутой найтивности X86 кода и отсутствия необходимости ставить фрэймворк.
При этом несмотря на казалось бы свою найтивность Delphi не может похвастаться даже своим быстродействием,
поскольку MS-овтовский оптимизирующий компилятор из p-кода генерирует практически идентичный по эффективности Дельфевому машинный код.
Даже VS IDE последних версий от MS уже удобнее Дельфевой.
Отладка в VS IDE тоже удобнее чем в Делфи. Например, можно сразу видеть все содержимое и структуру объекта в наиболее удобном виде, а не набор 16-ричных адресов как в Delphi. А возможность менять код без перекомпиляции и перезапуска всего проекта!...
Да чего там... — Продуманная, логичная и прекрасно документированная библиотека, а не архаичный и плохо-документированный VCL с тяжелым наследием. — Нормальные и функциональные generic-и, а не их обрезанное и глючное подобие в D2010 — продуманные датасеты и отсутствие в необходимости т.н. Датасоурсов, а как следствие и в отдельных дата-контролах — «наитивная» работа с XML — LINQ — и прочее и прочее...
IMHO: Только упертый баран еще может надеяться, что Embarcadero со своими весьма скромными возможностями хотя бы догонит MS.

Все остальные уже покинули или покидают тонущий и обреченный Delphi-карабль

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

В свое время Делфи был одним из лучших средств разработки. И правильно сравнивать не с.NET, а с тем же MFC. Господа, кому пришлось программировать на MFC? Нравилось? В Делфи было много интересных реализаций и идей. Поддержка CORBA. MIDAS. Огромная база сторонних компонентов. Для информации — тот же популярный DevExpress это изначально были Delphi-компоненты.

На Дельфи удобнее программировать. А для Плюсов больше написано различных библиотек, примеров, фрейморков. Посмотрите еще на C#.NET если планируете под платформу Windows писать приложения. Там и скорость раработки и удобство для программиста, большой набор примеров, решений. А так же есть такие вещи которых больше пока нигде нет=:) Windows Azure

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

ично я не верю, ни в оптимистичные, ни в пессимистичные прогнозы. Нет, Delphi отнюдь не мертв. И, наверняка не умрет в обозримом будущем. Это добротный, развивающийся продукт, имеющий и постоянно расширяющий свою аудиторию. Если нужны доказательства — извольте... Программа, управляющая подсветкой олимпийских колец в Ванкувере, написана на Delphi. Какие еще нужны доказательства того, что этому продукту доверяют во всем мире?

но вот перспективы под вопросом.

Помнится Паскаль в свое время тоже тонул до тех пор, пока Borland’ы не выпустили Delphi. Мож рано ее хоронить?...
В середине 90х у Borland была отличная команда разработчиков, поэтому и появился Delphi.
Сейчас, насколько я знаю, команда так себе, так откуда возьмется «новый» Delphi?

Никто Delphi не хоронит

MS запустила линейку Visual вдохновившись борландовским C++ Builder. Никакого Delphi тогда и в помине не было.

Это не так. Изначально был именно Delphi. C++ Builder повился позже как Delphi-подобный вариант C++ (приблизительно версия 1 билдера соответствовала версии 3 или 4 Delphi). И кстати, если в Delphi и была какая-то элегантность, то билдер был изначально диковат и разумеется прошедши через время он ни капли не изменился в лучшую сторону.

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

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

Прекратите насиловать труп (Delphi) — его создатель сейчас разрабатывает C# в Microsoft

JAVA (интерпретируемый язык)

Буга-га!!! Ты хоть сам понял что сморозил чушь???

Я сам на Делфи не пишу и разделяю общий настрой, но в теме откликнулось много «зубров»:) и сообщение для них.

Люксофт недавно искал дельфина

Сравни с «люксофт постоянно ищет жабистов и дотнетчиков»

Люксофт недавно искал дельфина

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

Флеймим по кругу:)
>> 1. Используемый язык программирования хорошо развит и стабилен (не путайте язык и набор библиотек).
Ну и кому в 2010 году нужен язык без библиотек?
>> Все «пошарпанные» языки были созданы в качестве прямого конкурента JAVA (интерпретируемый язык).
Т.е. C# — интерпретируемый? Без комментариев.
>> К сожалению монстр может родить только монстра.
Весьма занятный факт, но архитектор языка С# Anders Hejlsberg — именно тот человек, который написал TurboPascal, с которого начался дельфи. Но здесь я согласен с автором — поступив на работу в MS, Андрес стал < s> сотоной</s> монстром.
>> Лично я вообще не ставлю Microsoft.NET Framework, поскольку Microsoft никогда не умела гарантировать безопасность (почитайте хотя бы текст их лицензии).
Видимо в лицензии на Delphi написаны 100% гарантии.
>> Даже программы самой мелкософт на.net имеют проблемы с переносимостью. Microsoft.NET Framework — очередная дыра в безопасности.
Без комментариев. Monsters, monsters everywhere!
>> По большому счету, современные неинтерпретируемые языки достаточно близки по возможностям. А интерпретаторы предназначены для мелких прграмм или редко используемых, когда быстродействие не существенно.
Автор снова путает интерпретируемые языки и языки, компилирующиеся в p-code.
>> Что касается набора библиотек/компонентов, то и в настоящее время выпускаются сторонними фирмами хорошие компоненты, в том числе коммерческие. Кто ищет, тот всегда найдет.
Приведите примеры.
>> Borland в пылу конкурентной борьбы с мелкософтом попыталась втянуть в Delphi аналог того хлама, который поставляла мелкософт. Финансы не выдержали, потребители пострадали.
Все было вообще-то с точностью до наоборот — MS запустила линейку Visual вдохновившись борландовским C++ Builder. Никакого Delphi тогда и в помине не было. Финансы Борланда подкосила покупка dBase и неумение продавать (Paradox for Windows стоил $495, MS Access — $99, Quattro Pro/Win тоже был дороже MS Excel) Delphi был выпущен как Borland Pascal for Windows 95, в тот момент когда Борланд уже трещал по швам
>> Добавление.net в угоду моде — также было ошибкой, погубившей много финансов. Мелкософт всегда умела показывать на горизонте золотые горы, которые при ближайшем рассмотрении оказывались кучей мусора. Где сейчас их бейсик?
Везде:) В разы распространеннее, чем Delphi:)
>> То что Borland не выдержала конкуренции, не означает что Delphi плох. Мелкософт всегда вела нечестную конкуренцию.

Чистая правда. Как и то, что нечестная конкуренция со стороны MS вовсе не означает что Delphi хорош:)

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

sich, назовите мне, пожалуйста, плюсы Делфи (кроме быстрого рисования формочек).
В плане многопоточности, не-визуального программирования, (хорошо, кроссплатформенность оставим в стороне, кто там будет задумываться о том, чтобы запустить одно и то же ПО под разными ОС без лишних заморочек, правда?:)), работы со строками
Кстати, Вы в курсе, что они переписали length? Он теперь возвращает количество байт, а не количество символов.
Цитирую в общем их ответ с их же вебинара: «Придете к начальнику, скажете, что Вам нужно для перехода на Делфи 2010 неделя, месяц, год (!), начальник поймет, и выделит Вам этот срок, ничего страшного, главное, что Вы цифру озвучили»
Где, интересно, найдется начальник, который согласится год тратить на переписывание «готового/рабочего» проекта. Скажет — ну вас лесом, работаем на старом. И его можно понять.
Борланд протормозил, и вовремя не уловил тенденций. Сейчас Эмбаркодеро пытается эту гниющую плоть возродить, но такими методами революционными, что я оооочень сомневаюсь... Старые проекты старые поклонники переписывать вряд ли будут, а новые проекты новые поклонники (в силу стереотипов и прочего) — вряд ли не станут начинать.
Так вот. Скажите мне, чем же так хорош Делфи, кроме того, что его «нельзя сравнивать с ДотНетом»?
Многопоточность? Винапи? Может быть, эти их... Корбры?:)
Для чего он хорош, кроме формочек?

(на счет серьезно не работать — оговорюсь, не один год опыта работы в разнообразнейших «сферах» его использования)

Создается впечатление, что о Delphi пишут отзывы те, кто на нем серьезно не работал.
1. Используемый язык программирования хорошо развит и стабилен (не путайте язык и набор библиотек).
2. Некорректно сравнивать Delphi и C# (.net). Программы.net работают в своей специальной среде и не могут быть запущены непосредственно. Разные версии Microsoft.NET Framework не совместимы снизу вверх и поэтому зачастую требуется одновременное наличие их всех! Все «пошарпанные» языки были созданы в качестве прямого конкурента JAVA (интерпретируемый язык). С ним и нужно сравнивать. К сожалению монстр может родить только монстра. И для жизни монстра нужно много ресурсов. Лично я вообще не ставлю Microsoft.NET Framework, поскольку Microsoft никогда не умела гарантировать безопасность (почитайте хотя бы текст их лицензии). Даже программы самой мелкософт на.net имеют проблемы с переносимостью. Microsoft.NET Framework — очередная дыра в безопасности.
3. По большому счету, современные неинтерпретируемые языки достаточно близки по возможностям. А интерпретаторы предназначены для мелких прграмм или редко используемых, когда быстродействие не существенно.
4. Что касается набора библиотек/компонентов, то и в настоящее время выпускаются сторонними фирмами хорошие компоненты, в том числе коммерческие. Кто ищет, тот всегда найдет.
Что подкосило Delphi?
1. Borland в пылу конкурентной борьбы с мелкософтом попыталась втянуть в Delphi аналог того хлама, который поставляла мелкософт. Финансы не выдержали, потребители пострадали.
2. Добавление.net в угоду моде — также было ошибкой, погубившей много финансов. Мелкософт всегда умела показывать на горизонте золотые горы, которые при ближайшем рассмотрении оказывались кучей мусора. Где сейчас их бейсик?
То что Borland не выдержала конкуренции, не означает что Delphi плох. Мелкософт всегда вела нечестную конкуренцию.

Какой язык програмирования все таки лучший? Тот, который ты хорошо знаеш. Даже на.net можно сделать конфетку. А на хорошем языке...

Я не вижу проблемы. Какая разница что написано на Delphi? Если система работает?

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

Аргументи 1 не вдасться сказати про будь-який інструмент, тому що інструмент припускає вхідний поріг знань, для його використання. Не уявляю собі такого відношення до C++ програміста, чи до, наприклад, Haskell- чи LISP програміста. З іншого боку я писав про стереотипне відношення до такого собі сукупного Delphi-програміста. Тобто із того, що відношення є таким, не випливає, що кожен Delphi-програміст є «мишо-програмістом», а будь-який, хто написав C++ (або ж, навіть, Haskell) у своєму резюме — обов’язково магістр із Computer Science. Але відношення середнього роботодавця до середнього здобувача роботи буде апріорі таким.
Аргумент 3 теж не вдасться сказати про будь-який інструмент. Тому що я писав про «перманентно сирий софт». До речі, комерційний софт, що продається за гроші і немаленькі гроші! Чи може бути успішним такий софт, у якому помилки не виправляються роками? QT Creator і QT, наскільки я розумію, не сіноніми, та й QT Creator не такий старий продукт, якщо я не помиляюсь.

Якщо ніші поступово займають сильніші гравці, то хоча б в чомусь ці інструменти мають бути кращими (не обов’язково в усьому) інакше я не розумію, що у цьому випадку є силою.

Я не вижу проблемы. Какая разница что написано на Delphi? Если система работает?

Я не прихильник Delphi. Мало того, ми «калёным железом» випалювали бажання всунути щось з промислового на ньому (не завжди успішно) чи розпочинати нові проекти на ньому. Із «всучених» один проект вела баришня, толковий спец в ОРАКЛі, її з руками потім забрали звідти, тобто про неї «крайне положительное мнение». Я ось QT Creator на пробу поставив. Так він на першому ж тестовому вилетів, висновок, «„сырая“ среда». І що, QT — мертвий?
Я про те, що аргументи 1 і 3 (крім бібліотек), приведені Valentyn’ом можна про будь-який інструмент сказати, не факт.
Кожному інструменту — своя ніша. Ніші поступово займають сильніші гравці, не обов’язково кращими інструментами чи технологіями.

Тому загалом згоден, Delphi таки мертвий, бо майбутнього в нього нема, хіба що животіти де-не-де.

Хотите закончить свою IT-карьеру в болотце какой-нибудь ретроградно-совковой конторки, тогда Delphi — ваш выбор. В остальных случаях, смело проходите мимо и никогда не упоминайте в приличном обществе. Причины (без какого-либо порядка):
1. Крайне негативное мнение сложившееся в отношении к данному инструменту и людей использующих его.
Большинство привыкло считать, что уровень квалификации Delphi-программистов самый низкий и ничего кроме расстановки кнопочек мышкой и кодирования простейшей логики в обработчиках событий такие люди не умеют. Ах, да, ещё они умеют связываться с базами данных и отображать данные в сетках. А если вдруг нужно что-то, чего нет в палитре компонент, можно ведь всегда пойти в Интернет и поискать нужный кусок кода или готовый компонент, обаладающий желаемой функциональностью или спросить на форуме и получить ответ в виде куска кода, который с удовольствием и использовать, порою, даже не разбираясь в нём. Мне кажется, таких Delphi-программистов под 80% и я понимаю работодателей, которые услышав об очередном соискателе со словом Delphi в резюме, откажут ему, справедливо решив, что лучше уж не брать никого, чем рисковать и взять кого-то из этих 80%.
2. Delphi не является ни одним из промышленных стандартов, ни одним из модных трендов.
А следовательно найти для него качественные библиотеки в лучшем случае — очень трудно, а практически всегда — невозможно. А значит, прийдётся изобретать свои велосипеды или пытаться использовать двоичные модули. Это долго, дорого, некачественно и без гарантии позитивного результата.
3. Перманентно «сырая» среда и компилятор. Не доведённый до ума язык.
Что IDE, что компилятор Delphi — непростительно изобилуют ошибками. А некоторые ошибки не исправлялись многими годами. Среда может падать, пожирать память, CPU, зависать, мигать хинтами, оставлять артефакты на экране и т.д. В редакторе кода может отключаться и включаться auto-completion, и без того бедная навигация по коду может ни с того, ни с его сойти с ума, может вдруг начать помечаться, как некорректный весь код и т.д. Отладка многопоточных приложений с высокой вероятностью завершится намертво зависшей средой. Так было и в Delphi 7, так есть и сейчас, в Delphi 2010. В интерфейсе среды множество несуразиц и глупостей. Компилятор, особенно после «новшеств» языка, с огромным неудовольствием компилирует эти самые «новшества», очень часто просто останавливаясь с неизвестной ошибкой: что хочешь, то и делай — сам догадывайся, что именно и где ему не понравилось. Сам язык убог и никак не годится не то что к сравнению, но и к написанию рядом с таким языком, как C++. После Object Pascal/Delphi, C++ (которому приходится тянуть совместимость с C) кажется пределом мечтаний и самим совершенством.

Delphi мёртвый язык. Поверьте, он действительно мёртвый и кажется живым лишь благодаря тем самым «мёртвым», которые его до сих пор используют.

Он і в такому селі як Тернопіль вичитав є навіть вакансія

Странный вопрос. На делфи много чего и где пишут.

Був (є) такий собі кроссплатформенний (і для віндовс, і для юнікс) продукт PowerBuilder.
Дуже чудово було для баз формочки малювати, та й не тільки (PowerBuilder vs. Delphi не тут, не про це.)
Спочатку загнулась кросплатформність. Потім потроху і популярність.

Бо не тій фірмі продався. Так десь приблизно й Delphi так. Чудовий продукт, але «не судьба».

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

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


Знаю одну большую систему, которую хотят перевести под Линукс, но не могут из-за того, что она написана на Delphi. Выбрав C++ & Qt они бы такой проблемы не имели. О чём они раньше думали непонятно.
«Знаю одну большую систему, которую хотят перевести на Java, но не могут из-за того, что она написана на COBOLe. Выбрав ALGOL они бы такой проблемы не имели. О чём они раньше думали непонятно».: -)

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

Знаю одну большую систему, которую хотят перевести под Линукс, но не могут из-за того, что она написана на Delphi. Выбрав C++ & Qt они бы такой проблемы не имели. О чём они раньше думали непонятно.


Кто считает, что Делфи хорош только рисованием формочек, тот с ним, скорее всего, полноценно и не работал.

Вот, например, сделайте на.NET что-то вроде этого armor.kiev.ua/wiki/index.php title=%D0%A2−64_%28CD, _2005%29, чтобы юзер вставил диск и сразу начал с ним работать без установки десятков, а иногда сотен, мегабайт самого последнего фрейворка, который ему на компе ну просто необходим как воздух (с точки зрения программера, конечно).

Розчарую, а таки в останніх версіях вінди фреймворк вже є в дистрибутиві. В будь-якому випадку є така річ як Qt який не потребує нічого.

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

Ну тут треба мізки мати... Хоча штука реально потужна.


Це все викликає лише посмішку.
Так само, як і проект на Делфі (Нумератор), яким автор дуже пишається.:)

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

Якщо комусь цікаво — компонент на C#, що робить набагато більше
Очень интересно. Что он делает много больше? (это без ехидства, реально интересно)
Судя по диаграммам, подход к решению у нас одинаковый.

Кстати, по диаграммам замечание: тяжело читаются, много лишних деталей, диаграмма должна показывать идею, это все же не программный код, лучшее документирование которого сам программный код; -) Но это замечание по форме, а не по сути.

Вам не нужен юникод,

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

Delphi — изумительный инструмент

Видимо, Вам не приходилось в Делфи работать с многопоточностью через их TThread, Вам не нужен юникод, Вам приятно работать с ОЛЕ и вариантами в их реализации в Делфи, а так же, наверно, не приходилось портировать шарповый код с помощью дисп-интерфейсов, т.к. «других вариантов нет» (желание заказчика + нет реализации не на.Net языках)
4+ года промышленной разработки на Делфах

считаю бесперспективным

Получив прототип, два программиста на C# делали это (фактически — повторяли) месяца полтора...

Це все викликає лише посмішку.
Так само, як і проект на Делфі (Нумератор), яким автор дуже пишається.:)
Якщо комусь цікаво — компонент на C#, що робить набагато більше + повністю документований + покритий тестами (здається на 85%) і що був написаний за один тиждень.
Serial Number Generator

Мені дуже прикро, що автор знайомий лише з двома хорошими спеціалістами, які використовують C# для вирішення проблем своїх клієнтів.

но если нужно что то по быстрому написать под вин32 — кроме делфи вариантов нет...

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

А вобще по-настоящему Дельфи вынесут те ребята, которые прикрутят быструю рисовалку формочек к Питону.

Delphi — изумительный инструмент
Плохо, что у борладндов не хватило мозгов на грамотный маркетинг, что привело к сливу
продажа тоже ничего не изменила...,
но если нужно что то по быстрому написать под вин32 — кроме делфи вариантов нет... с.нет у них проблемы. всему виной — агрессивная политика мелкософта в плане стандартов, редакций и т.п. актуальной будет являться только последняя версия студии. пусть и «експресс»
тут все сторонние конторы будут отставать на два-три шага...
Текущий разработчик вроде планирует опять запустить кроссплатформенность на мак, вин, *никс.

че из этого выйдет — покажет время

История про то как с Delphi на.NET (C#).
Будучи представителем заказчика, представителям компании разработчика (крутой компании-разработчика) на C# реально задолбался писать требования и рисовать интерфейс — не в коня корм. Решил накидать прототипы в Delphi. Каждый прототип у меня занимал от 1 до 3 рабочих дней. Прототип не только интерфейса, но и отчасти работал бизнес-функционал (глубина реализации бизнес-функций от 20 до 90%).
В том числе, долго просил сделать настраиваемый нумератор документов, в ответ «два месяца». За два дня накидал на Delphi работающий прототип с правильно спроетированными классами нумератора, ориентированными на бизнес-логику.
Получив прототип, два программиста на C# делали это (фактически — повторяли) месяца полтора...
Недавно, потратив три вечера, я из спортивного интереса довел прототип до полноценно реализованной подсистемы, готовой к повторному использованию в любых проектах, в которых что-то нумеруется способом, отличным от простого номера по порядку (как правило, документы).
Подробности тут:
armor.kiev.ua/wiki/index.php title=%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA: ArmorAdmin/%D0%9D%D1%83%D0%BC%D0%B5%D1%80%D0%B0%D1%82%D0%BE%D1%80
Кто считает, что Делфи хорош только рисованием формочек, тот с ним, скорее всего, полноценно и не работал.
Вот, например, сделайте на.NET что-то вроде этого armor.kiev.ua/wiki/index.php title=%D0%A2−64_%28CD, _2005%29, чтобы юзер вставил диск и сразу начал с ним работать без установки десятков, а иногда сотен, мегабайт самого последнего фрейворка, который ему на компе ну просто необходим как воздух (с точки зрения программера, конечно). Кстати, ссылку дал не просто так, при просмотре текстов используется полноценный текстовый RTF-редактор (в режиме чтения), написанный на Delphi в 1999−2001 гг. без использования rich-библиотек от Мелкософта, только Паскаль, ассемблерные вставки и WinAPI.
P.S. Споры о том, какой язык лучше, из разряда религиозных, поэтому я в них не участвую. Но поработав несколько последних лет в проектах на.NET, у меня выработалось к этой технологии стойкое отвращение. Может быть потому, что среди многих десятков программистов си-шарпников знаю только двоих, которые думают не уровнем технологий, «фич» и «библиотек», а вникают в проблемы пользователей, для которых пишут код.

P.P. S. Единственная толковая программа, которая мне известна на.NET, это Paint.NET.

to eugene_n

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

Таки да: о) Delphi 3 + AsyncPro — выбор последних 10 лет: о)) Быстро создал тестовое ПО (и таки да — на проверку обмена) и все: о))

to flymanЗа строгость типов — да, есть такое...

2eugene_n

А что же такого в есть Делфи, чтобы его уважать?
Там какая никакая строгость типов, а не такая xyіта, когда на лету делаеш каст, и тебе всё пофиг.
Но весь маркетинг в том, что пришёл C#, и Делфи утратил смысл.
Если б он был продуктом мелкософта, то Делфи оставался мейнстримом.
Вообще-то борланду надо было сделать свою ось, и на ней вращаться.
А быстро сбацать на коленке достаточного и этого:

www.digimars.com/index.html

2 Андрей
>> Каждая технология/язык программирования etc. создаются не для того чтобы утешить очередного программиста новой фичей, а для решения прикладных задач
С обеими частями утверждения можно поспорить (для каких-таких прикладных задач создавались Smalltalk или там Huskell), но бог с ним.

Но ответьте пожалуйста — для решения каких прикладных задач delphi был создан изначально? Win32 desktop, не так ли? — в процессе своего длительного развития, произошли ли какие-либо изменения в этом списке задач? Интересуюсь искренне, Дельфи не видел лет 5 уже, мой опыт с ним сходен с опытом eugene_n — в определенный момент выяснилось, что «слепить формочку» намного быстрее и удобнее на VB, а больше задач для Дельфи как-то и не видно. — вот эта вот «ниша» задач, где Дельфи — идеальный выбор по сравнению со всем остальным, она насколько широка в данный момент?

подразумевает некую степень иронии свашей стороны

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

To eugene_n:

быстро слепить графическое приложение на коленке

подразумевает некую степень иронии свашей стороны поетому не соглашусь с вами в полной мере. Но в некотором смысле ви действительно правы: Delphi позволяет быстро (а для заказчика это слово звучит и как «дешево» ) сделать графическое приложение — например для работи з базами данных. Конечно я не буду отстаивать точку зрения что на Delphi стоит разрабатывать веб приложения или низкоуровневые вещи. Согласитесь, каждый инструмент хорош для решения своих специфических задач. Именно в таком ключе я и рассматриваю Delphi.

Delphi нужен для того, чтобы потом переписывать на NET:). Это же сколько денег надо на переписывание тратится

А у вас сколько опыта разработки на Delphi?

Не очень много. В основном это связано с тем, что Делфи позволяли быстро рисовать формочку. Когда же дело доходило до многопоточности и сторонних библиотек (в моем случае djvu) Делфи начинал очень круто пробуксовывать. Поэтому я просто уделил некоторое время изучению wxWidgets и gtk и забыл поделие Борланда как страшный сон.

В настоящее время я позиционирую его как средство быстро слепить графическое приложение на коленке. А вы?

To usix:

Ну что ж, я как человек которому приходится работать и на.NET и на Delphi могу сказать следующее: вы абсолютно правы. И вам как человеку который имеет опыт разработки и на и на.NET и на Delphi должно быть известно все pro and cons каждой из упомянутых технологий. И вы вероятно не написали бы ничего из ниже перечисленого:

Вона ще довго-довго житиме, бо її у вузах викладають.

Delphi мертвый язык? Да, и уже даже не пахнет.

сейчас это просто маргинальная экзотика

Паскаль подохне остаточно, коли повиздихують викладачі, котрі нічого крім паскаля не знають.

итд...

Мои коментарии были для тех кто ето написал ибо они видимо знают о Delphi только по наслышке.

2 Андрей
В течение нескольких лет разрабатывал крупный проект на Delphi. Потом принял решение перейти на.NET. Главная причина — желание иметь однородную среду для разработки серверной части, десктопных клиентов и веба. (до этого был микс Delphi + python).

В последствии стали очевидны дополнительные бонусы: — Более широкий выбор технологий, компонент, библиотек (не UI), по сравнению с теми, что доступны для Delphi. — Меньше шансов внедрить критические ошибки в систему у младших разработчиков. (В силу отсутствия указателей и прочих радостей неуправляемого кода.)

To eugene_n:
А у вас сколько опыта разработки на Delphi?

Каждая технология/язык программирования etc. создаются не для того чтобы утешить очередного программиста новой фичей, а для решения прикладных задач. Я работал над созданием систем на Delphi которые обслуживали предприятия со штатом в несколько тысяч людей. И если технология позволяет решать такие задачи — то уже только за это ее надо уважать. И если технология позволяет переводить кубические дюймы в... то и за ето ее нужно уважать.

Delphi не в почете потому что просто так принято — єто как будто правило хорошего тона.

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

В принципе у Делфи осталась изначальная ниша — среда программирования для непрограммистов. Делфи на ура идет у инженеров, которые пишут на нем всякие калькуляторы для перевода кубических дюймов в квадратные футы и опросы удаленных датчиков через СОМ-порты.

Вариант ГУЙ — на делфи, Функционал на плюсах мы уже не рпссматриваем? ИМХО в прошлом такой тандем был популярен для виндовс-десктоп приложений

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

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

Я сам долгое время работал на Delphi (да и сейчас немножко) и складывается впечатление что Delphi не в почете потому что просто так принято — єто как будто правило хорошего тона. Я это очень часто вижу ещо с института. Да все учили Delphi в институтах, но вот просто интересно, сколько из висказавшихся здесь имеют комерческий опыт работы с этим продуктом/технологией. Множество мнений которие я слышал о Delphi в своей жизни исходили от людей у которых весь опыт работы с Delphi это 5−10 лабораторных работ.

Ни чего не могу сказать про Делфи как фреймворк для разработки, но с точки зрения карьеры, за 6 лет активного мониторинка ИТ рынка Финляндии вилел всего 3−5 вакансий, т.е. меньше чем одно предложение в год. Так что делайте выводы.

Зато Паскаль правильно с массивами работает

Сергей Волошин, а може бейсік? він то взагалі 1963й...

Вариант ГУЙ — на делфи, Функционал на плюсах мы уже не рпссматриваем? ИМХО в прошлом такой тандем был популярен для виндовс-десктоп приложений

В линуксе он мог бы быть написан с помощью Kylix, там как раз и Qt и C++.

Скайп работает не только под Windows. В Линуксе он использует С++ и Qt. Странное решение использовать Delphi для Windows. Видимо вначале была версия для Windows сделанная неподумав, а потом пришлось поддерживать два языка, жуть:)

В списке ошибка, Скайп написан на C++

Паскаль подохне остаточно, коли повиздихують викладачі, котрі нічого крім паскаля не знають.

П.С. І сказала сьогодні наша викладачка (з кафедри програмування доречі) С то продовження Паскаля

Delphi, по субъективному ощущению человека с ним работающего, сейчас завис на перепутье, после некоторого спада, связанного с быстро прошедшей эйфорией.Net.
Оч позитивно сказалось на нем то, что он ушел из рук Борланд, погубившего не мало замечательных продуктов.
В десятку по tiobe он вернулся http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html. Что дальше — покажет ближайшие 2 релиза от нынешнего его владельца, по меньшей мере движутся они активно и в верном направлении.
Для своей ниши (десктоп и нативные приложения), которая в последнее время стала значительно уже, он является вполне адекватным выбором. Из основных недостатков видится слабая околопроцессная обвязка самой платформы — CI, scm, тестирование... и таки да, меньшее кол-во дешевых спецов.

PS да, а соответствующих вакансий в последнее время стало больше — похоже в Украину зашли зарубежный проекты на Delphi.

Дался вам этот Парус:) Вы над ним/с ним работаете? Вам не понравилось слово «маргинал», предпочитаете «малая доля рынка»?:)
Юмор ссылки про 1C в том, что мейнстримным продуктам не требуется рассказывать о своих клиентах, testimonials или списки подобные тому что привел Сергей Волошин. Все это пыль в глаза, претензия на то, что «мы (все еще) работаем на горизонтальный рынок»
OK, если вас это успокоит, Дельфи как продукт не мертвый (хотя и на последней стадии), он официально развивается и вероятно даже продается в количестве достаточном для поддержания штанов команды его разработчиков. Там не такие большие деньги нужны, и таких продуктов, зачатых в бурных 90х, — все еще сотни, если не тысячи. Да че там стесняться — Doom for Windows тоже можно до сих запустить и погамать (я проверял — под Вистой идет:). Можно даже пару wad’ов нарисовать и продать через ибэй сорокалетним фанатам. Доказывает ли это что Doom — живой продукт? Сомневаюсь.

Дельфи же как технология де-юре мертва с момента ее перехода на.Net. И это после относительно безоблачного прошлого, что вдвойне обидно. Сразу вспоминается полуось:) Факты же в том, что разработчики Паруса (ну и PLSQL developer’а) попали в довольно неприятную ситуацию — часики тикают, спецов по Дельфи будет только меньше и гарантий что все нужные в будущем фишки можно будет сделать — никаких, надо или мигрировать куда-то, или с нуля писать, и неизвестно что лучше. Оракл-то, я уверен, выкрутится — пригласят пару лишних раз клиентов на гольф и втюхают таки им свой продукт пятилетней давности, им не привыкать. Бухгалтерия тоже, за счет vendor lock-in, побарахтается еще какое-то время. Но начинать новый проект на Дельфи — самоубийство.

to andy

:)) v8.1c.ru/buhv8

не понял юмора, ну возможности 1с, ну и что
Парус, в отличичие от 1с-ки, используется в крупных компаниях по той ссылке большой список клиентов, значит он не маргинал

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

Сейчас какой то почитатель сей штуки выдаст, что-то типа: «Контр страйк написали у Делфи»...

насколько знаю, так называемый «старый Qip» автор написал на делфи, потом видимо понял, что не, фигня, и переписал «с нуля» на Qt и назвал его Infium (:

А QIP точно на делфі? Бо чув, що він на Qt.

Ну, а про стартап The Bat-овців легенди ходять:) В ті часи Делфі ще було конкурентно спроможне.

Ну, бизнес-процессы Оракла и во что он превратился в последние 10 лет — это отдельная тема. И на каком кстати, Дельфи? Древнем борландовском, CodeGear, Embarcadero? Что вы, собственно, пытаетесь доказать — что Дельфи — это мэйнстрим?
> www.parus.ru/index.php page=302

:)) v8.1c.ru/buhv8

ну те кто с ораклом работает меня поймут эти три PLSQL Developer, Toad и SQL Navigator написаны не в бывшем ссср и почему-то на делфи. Сам оракл сделал свой developer на Java, но он, почему-то, не такой популярный.

это просто маргинальная экзотика (как и Парус Бухгалтерия:)

www.parus.ru/index.php page=302

А также Лисп, Хаскел и Ассемблер.

самый обычный паскаль очень удобен для изучения программированию с «нуля».

Согласен, что у Делфи практически нет будущего, посему стоит взглянуть в сторону шарпов и java.

ЗЫ. В смысле «только студенты и учат Паскаль»:)

На нынешнем этапе — мертвый. Поскольку индусы и китайцы на нем массово не пишут и в бизнесе не применяется. Студенты учат Паскаль

Дельфи — развитие Турбо Паскаля, который был успешным продуктом в 80х — поскольку расцвет Паскаля как языка для персоналок как раз пришелся на 80е- массово пиратился в ex-USSR, что объясняет популярность Delphi здесь. В начале 90х Борланд выпускал одни из лучших средств для программистов (MS болтался где-то в середине Top 10, были еще Watcom, Zortech/Symantec, TopSpeed и несколько других игроков) и Кан решил потягаться с Майкрософт по-взрослому, прикупил офисный пакет и пр. Вскоре случился Windows, затем Windows 95, а также средства разработки от MS для них, Борланд не выдержал конкуренции с Visual Studio (в основном, конечно, с MS Office, где крутились совсем другие деньги) и сошел со сцены. Delphi окончательно выпал из обоймы, в которую в принципе толком и не успел попасть — ниша был занята VB — сейчас это просто маргинальная экзотика (как и Парус Бухгалтерия:)

Кроме того почти у каждого стоит, что-то из этого популярного ПО:

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

Delphi мертвый язык?

Да, и уже даже не пахнет.

Не тупи, чувак. Делфі — то не мова. То технлогія.

А мова — Паскаль. Вона ще довго-довго житиме, бо її у вузах викладають.

Підписатись на коментарі