Сам работаю с oracle, недавно обнаружил, что такие известные функциональные программы как PLSQL Developer, Toad и SQL Navigator сделаны на Delphi.
Кроме того почти у каждого стоит, что-то из этого популярного ПО:
— Total Commander
— The KMPlayer
— Light Alloy
— QIP
— Download Master
— The Bat!
— FastStone Image Viewer
— FastStone Capture
— Парус Бухгалтерия
которое написано на Delphi.
Почему же тогда говорят, что этот язык отмирает?
Варт Дейдер 8 мин. назадБыл вчера на этом форуме — поржал с комментов.
Народ, а как думаете, эти олухи свою поделку тоже на делфе делали?
Жалко ведь людей.
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-к приммеру).
Мелкие и неответсвенные утилиты, типа учета рабочего времени и автоматизации повседневной работы.
Веб — мелочь на php, крупное на Java, еще Asp.Net очень хвалят (но никогда не работал).
Смотря что понимать под внутренним.
Мелкие и неответсвенные утилиты, типа учета рабочего времени и автоматизации повседневной работы. Ну например загнать на формочку какую-то часто используемую в работе формулу из сопромата или там вычисление реактивной мощности. Можно конечно и в Экселе, но в Делфях более интуитивно понятно, и экзешники можно копировать.
eugene_n 3 мин. назадКлючевое слово. Здесь Делфя безусловный лидер...
Смотря что понимать под внутренним. Если предприятие не устраивает 1С, то можно нанять программиста который за год на готовом фреймворке напишет ПО для внутреннего использования (в том числе и web) под бизнес-процесс, а не погнёт бизнес-процесс под ПО. А суммарная прибыль от этого может измерятся в сотнях тысяч долларов.
программки для внутреннего использования,
Ключевое слово. Здесь Делфя безусловный лидер...
Варт Дейдер 8 мин. назад
Народ, а как думаете, эти олухи свою поделку тоже на делфе делали?
Можно и на Delphi, виртуальные десктопы можно создавать начиная от Win2000. Просто оно никому не нужно, так как проще поставить RDP терминал за 100$ к которому и подключать всё.
Delphi на сегодняшний день применяется лишь на загибающихся предприятиях вышедших из СССР. Руками студентов пишутся программки для внутреннего использования, руководит этим дяденька лет 60 -.ти. Зарплаты там маленькие, под час меньше чем у слесаря, Правда делать ничего не нужно.
Смотреть по максимально возможному глупая затея, по ряду причин. Но если все таки глянуть, то:Если смотреть по максимальным зарплатам, то разницы между Java и Delphi почти нет.
Кстати, со всей Украиной такая же история, как и с ЗП в Киеве.
qwerty_smerty 5 час. назадЕсли смотреть по максимальным зарплатам, то разницы между Java и Delphi почти нет. А минимальный вход всё таки проще в Delphi так как Delphi для дескткопа это как php для веба. Так что мышкой писать ПО на Java все таки довольно сложно, а на Delphi возможно.
На дворников тоже спрос есть, или кто нибудь сомневается в их полезности? Средняя зарплата дельфина 1250 баксов, жабиста — 1837 Имхо, разница что называется на лице. Ещё раз, делфи это в основном допиливание старых проектов
Хотя джуны в Delphi почти уже не требуются, а для сеньеров работу найти не так уж и сложно.
изучать нефиг, самим мало. Но спрос есть.
На дворников тоже спрос есть, или кто нибудь сомневается в их полезности? Средняя зарплата дельфина 1250 баксов, жабиста — 1837 Имхо, разница что называется на лице. Ещё раз, делфи это в основном допиливание старых проектов.
И поскольку уточнение определения давалось чайником, вместо определения танка мы получили САУ.
76.2 мм это «крупнокалиберное пушечное»? А 45 мм? А 37 мм? А, как Вы думаете, пулемётных танков не бывает?Вы предсказуемы. Легко поддались на уловку и полезли демонстрировать оригинальность мышления в области, в которой не шарите. Ламер всегда ведет себя как ламер.
Да, я ламер в бронетехнике, как и ты в программировании.
qwerty_smerty 59 мин. назадВ общем-то да
Заходим сюда — же на девелоперс, в раздел вакансии. Смотрим на количество оных по.NET, Java, Flex сравниваем с количеством по Delphi.Потом сравниваем зарплаты и делаем вывод о целесообразности изучения делфи
Так что изучать нефиг, самим мало. Но спрос есть.
Потом сравниваем зарплаты и делаем вывод о целесообразности изучения делфи
А казалось бы — добавь к определению фразу: «оснащенная крупнокалиберным пушечным вооружением в качестве основного», и вопросов бы стало значительно меньше.И поскольку уточнение определения давалось чайником, вместо определения танка мы получили САУ.
Вы предсказуемы. Легко поддались на уловку и полезли демонстрировать оригинальность мышления в области, в которой не шарите. Ламер всегда ведет себя как ламер.
Мир приблизился к хаосу, когда быдлокодеры бросили Делфи и перешли на пых-пых
С меня потребовали пример, где бы наследования не было бы буквально. Я привёл.
Ты убрал наследование используя особенности языка (динамическая типизация, reflection), на С++ бы такое не прокатило очевидно.
А казалось бы — добавь к определению фразу: «оснащенная крупнокалиберным пушечным вооружением в качестве основного», и вопросов бы стало значительно меньше.Вот, например, классическое определение: «Танк — боевая гусеничная машина, сочетающая в себе такие основные свойства как огневая мощь, защита и подвижность.» Профессионалов оно никогда не смущало и не смущает, ламеры постоянно недоумевают почему оно такое «кривое», ведь под него можно подвести и БМП, и гусеничные БТР, и САУ и др. технику.
Это я к тому что если думать над качеством выражения свох мыслей, то количество недопониманий уменьшится многократно.
Занавес.
Василий Чобиток, а у вас есть IT-образование и связанный не с интерфейсами опыт написания программ?
Видите ли, Аноним, оппоненту не интересна суть сказанного, он тупо привязался к буквальной интерпретации слов, подходя к разговорному языку с позиций булевой логики. С меня потребовали пример, где бы наследования не было бы буквально. Я привёл. На самом деле этот факт меня не радует и не огорчает, просто хотели получить буквальное соответствие — получите.А вы так радуетесь, что там нет наследования (только потому что ПХП), хоть все эти классы алгоритмов без наследования все равно обязаны содержать одинаковый метод.
Просто кроме энциклопедического краткого определения, которое приводится в преамбуле любого букваря, дальше есть множество глав, посвященных предмету.
Абстрактный класс или интерфейс, или совсем ничего — неважно, главное что пользователь этого «неважно» для вызова стратегии использует одинаковую сигнатуру метода. Как вижу средства ПХП позволяют вызывать метод задавая имя класса на ходу (с ПХП не знаком и это мои догадки), ну что же, хорошо. Это все равно, что в.NET я буду вызывать метод неопределенного класса путем Reflection. И я прицепился к вашей фразе, что «наследование не нужно, но это и не важно». Хоть наследуетесь, хоть нет, у вас все классы алгоритма распределения напрямую зависят от класса-пользователя алгоритма distribution. Все они должны содержать метод distribut. А вы так радуетесь, что там нет наследования (только потому что ПХП), хоть все эти классы алгоритмов без наследования все равно обязаны содержать одинаковый метод. И это смешно.
если народ не понимает, может же быть причина и в примере?
Но это неверно. А верно — завести абстрактный класс 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бил. Спасибо за «дискуссию».
Скажите, а если бы вместо абстрактного класса я использовал интерфейс, это тоже не соответствовало бы шаблону Стратегия?; -))А ничего, что паттерн стратегия предполагает абстрактный класс
P.S. Меня всегда раздражало, когда в те же статьи о шаблонах проектирования в Википедии быдлокодеры радостно впихивали обширные примеры кода на языках. Программист должен быть способен понимать идею, вникнуть в суть, а реализация — дело техники.
в примере с распределением судебных дел даже наследования нет, но это не важно!!!
Цитата с сайта:
А ничего, что паттерн стратегия предполагает абстрактный класс, а реализующие его классы и реализуют собственно различные стратегии алгоритма, да и в вашем примере метод distribut имеет одинаковые сигнатуры в различных классах,Для обеспечения возможности подключать другие алгоритмы первый алгоритм serial инкапсулирован (используем шаблон проектирования Strategy)
Вы кого за нос водите? Может стоит почитать еще что-нибудь кроме Шаллоуея?
+1Инкапсулировано может быть «где-то». Нельзя инкапсулировать «от чего-то». Если вы хотите написать просто «сокрыто», так и пишите. А то применяете его в совершенно левом контексте. Нельзя ведь сказать «десантник подбежал к западной части дома и инкапсулировался в кустах»? Или вы употребляете этот термин в целях повышения значимости фразы?
Меня не покидает надежда, что под инкапсуляцией в своем примере Василий имел в виду что наследники классов TDocument, TTextFilter инкапсулируют в себе логику и данные специфичные для текстовых форматов.
Инкапсулировано может быть «где-то». Нельзя инкапсулировать «от чего-то». Если вы хотите написать просто «сокрыто», так и пишите. А то применяете его в совершенно левом контексте. Нельзя ведь сказать «десантник подбежал к западной части дома и инкапсулировался в кустах»? Или вы употребляете этот термин в целях повышения значимости фразы?
1) Сутки назад я приводил цитату из книги «Шаллоуей, Алан, Тротт, Джейм, Р. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию: Пер. с англ. —М.: Издательский дом „Вильямс“, 2002.» Найдите и прочтите, это более чем достаточное объяснение.
Ок, согласен, этот твой коммент я продолбал.
2) Кроме модификации примера про TDocument, я приводил ссылку на другой пример, в котором инкапсуляция на уровне проектирования, а не средствами языка.
Я просил короткий локаничный пример, выискивать здравую мысль в куче говна мне недосуг, извини.
В моем примере изменчивая часть (разные форматы хранения) «вынесена за скобки» и инкапсулирована (скрыта, Вы же согласились, что инкапсуляция — сокрытие) от основного класса TDocument. Мы устранили наследование «основной системы», добавление новых форматов не затрагивает своими изменениями TDocument, а есть там наследники или нет TDocument не знает, от него инкасулировано (в примере с распределением судебных дел даже наследования нет, но это не важно!!!).
В примере когда у TDocument есть наследники, TDocument о них тоже ничего не знает. Так что инкапсуляция есть в обоих случаях, как и ерархия наследования: иерархия наслендиков от TDocument и иерархия наследования TTextFilter (выбор имени класcа похоже свидетельствует о необратимых психических растройствах у автора).
собственные нахально оформленные вопросы интересуют больше, чем терпеливые ответы на них? Почему не читаете?
Ну, значит, как говорят, не в коня корм и нужных книг Вы в детстве не читали.
Перестаньте демонстрировать воинствующее невежество и почитайте полезную литературу.
Хамливое бла-бла-бла как всегда списываю на старческий климакс.
Перечитывая твои посты я нашел, одно место, которое можно принять за обьяснение понятия инкапсуляции:1) Сутки назад я приводил цитату из книги «Шаллоуей, Алан, Тротт, Джейм, Р. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию: Пер. с англ. —М.: Издательский дом „Вильямс“, 2002.» Найдите и прочтите, это более чем достаточное объяснение.
Вас собственные нахально оформленные вопросы интересуют больше, чем терпеливые ответы на них? Почему не читаете?
Возвращаясь к твоему примеру, то от него требовалось показать как наследование заменяется инкапсуляцией. В твоем примере одна иерархия наследования с инкапсуляцией, заменяется на другую с инкапсуляцией. Как бы очевидно что пример неудачен.Ну, значит, как говорят, не в коня корм и нужных книг Вы в детстве не читали. В моем примере изменчивая часть (разные форматы хранения) «вынесена за скобки» и инкапсулирована (скрыта, Вы же согласились, что инкапсуляция — сокрытие) от основного класса TDocument. Мы устранили наследование «основной системы», добавление новых форматов не затрагивает своими изменениями TDocument, а есть там наследники или нет TDocument не знает, от него инкасулировано (в примере с распределением судебных дел даже наследования нет, но это не важно!!!).
Перестаньте демонстрировать воинствующее невежество и почитайте полезную литературу.
Инкапсуляция — сокрытие
Ок, согласен, это одно из двух определений понятия инкапсуляции распространенных в литературе.
Сутки назад я объяснил, в том числе с цитатой.
Перечитывая твои посты я нашел, одно место, которое можно принять за обьяснение понятия инкапсуляции:
TdocFilter, ThtmlFilter и т.д. — его наследники, но TDocument о них не знает, это и есть инкапсуляция.Ты это имеешь в виду?
Возвращаясь к твоему примеру, то от него требовалось показать как наследование заменяется инкапсуляцией. В твоем примере одна иерархия наследования с инкапсуляцией, заменяется на другую с инкапсуляцией. Как бы очевидно что пример неудачен.
Инкапсуляция — сокрытие. Сутки назад я объяснил, в том числе с цитатой. Вам не понятно? Каких ещё объяснений ждете? Как пройти на курсы по ООП для начинающих или на углублённые курсы раскормленных троллей?
Кстати, если хочешь быть конструктивным, а не пустобрехом, все еще жду обьяснения что такое по твоему мнению инкапсуляция.
Простите, но я с Вами на брудершафт не пил.
Это меня к чему то обязывает?
Быдлокодером Вы сами себя идентифицировали: «ты мне ответишь на понятном мне быдлокодерском языке»
Эээ, я где то пропустил, где в этой фразе я себя называл быдлокодером? Проблемы с логикой?
P.S. «Ох уж эти горе-архитекторы...», «Жесть, горе орхетектор-теоретег детектед.» Следили бы за собственным языком, не пришлось бы невинную оскорблённость изображать.
Я по прежнему считаю что назвал вещи своими именами.
Delphi прекрасный язык, среда и вообще Borland, но время быстро двигается вперед, предоставляя нам новые и новые возможности. Я когда-то использовал это в своих разработках. Все зависит с чем и для чего это делается. Потом многое зависит от того, кто это делает. Если вы хотите быстро (3 дня) создать GUI приложение, которое работает с БД или еще с чем-то, если у вас есть необходимые компоненты (увы большиство из них платные, поэтому их трудно найти, зато легко купить если вы можете себе это позволить). Потом нужно много, много этих компонентов, и создавать свои тоже приходится, но в основном технология оработанная и вам не нужно многое придумывать снова. Если вы не боитесь технической поддержки и готовы с радостью сопровождать свои приложения. Есть приложения, написанные на Delphi, которые приносят реальную пользу. Но, я бы не сказал, что эти приложения пишутся легко. Сам Delphi и pascal уходят корнями в более узкую сферу программирования низкого уровня. Вся эта эйфория от высокоуровнего использования компонентов уже давным давно прошла, хотя многие до сих пор понимают только это. Это была большая стратегическая ошибка, на мой взгляд, со стороны компании, распространяя подобную чушь среди пользователей. С другой стороны pascal и delphi больше подходят для
Раз ты уже не в первый раз меня непрекрыто оскорбляешь я буду называть тебя быдлонедоархитектором, ты ведь не против?Простите, но я с Вами на брудершафт не пил.
Быдлокодером Вы сами себя идентифицировали: «ты мне ответишь на понятном мне быдлокодерском языке»
Как для уборщицы, понятно?Раз уж Вы так настаиваете кому какой вопрос задавали... Этот мой вопрос был адресован не Вам, а тому же Софту. Так что не рефлексируйте.
P.S. «Ох уж эти горе-архитекторы...», «Жесть, горе орхетектор-теоретег детектед.» Следили бы за собственным языком, не пришлось бы невинную оскорблённость изображать.
То, что быдлокодеры по узости кругозора
Как для уборщицы, понятно?
Раз ты уже не в первый раз меня непрекрыто оскорбляешь я буду называть тебя быдлонедоархитектором, ты ведь не против?
То, что быдлокодеры по узости кругозора и буквальности перевода называют дизайном, есть архитектура или конструкция (в машиностроении), а процесс — проектирование или конструирование.
О да, навязывать свою особенную супергениальную терминологию — это типичный прием тролей-быдлонедоархитекторов.
И, кстати, меня не интересует Ваше мнение по поводу инкапсуляции.
А меня не интересует что там тебя интересует. Ты как бы ввязался в мой вопрос к Софту. Если невоспринимаешь чужие аргументы или критику, то зачем писать на форумах? Из-за нарцисизма?
Спор с узколобым пониманием определения инкапсуляции в языке программирования из википедии мне не интересен.
Только создается впечатление что твое широкое и гениальное понятие инкапсуляции родилось исключительно в твоем нездоровом мозгу. Хотя это типичная болезнь быдлонедоархитекторов. Или все таки гениальный быдлонедоархитектор снизойдет до объяснения что такое инкапсуляция в его гениальном понимании?
Чи автора цікавих статей про iнжекти, перехвати системних функцій в 3 та 0 кільцях системи «МS-REMa».
2 prosto
камінь закладенний борланд. Пакунки відкомпільовані різними версіями компіляторів є несумісні.
Те саме у Borland C++ Builder
Твой пример как на мой скромный быдлокодерский взгляд задизайнен неудачно (вообще дизайн — далекио неточная наука, и содержит элемент исковства, но этот конкретный пример я бы задизайнил по другому), и я не согласен что то что ты там называешь инкапсуляцией, ей является.Там нет дизайна. То, что быдлокодеры по узости кругозора и буквальности перевода называют дизайном, есть архитектура или конструкция (в машиностроении), а процесс — проектирование или конструирование. Проектирование — наука точная, кто бы что не говорил, только им должны заниматься люди разбирающиеся в программной инженерии. А вот дизайн в самом деле часто не поддается точному описанию и многие успешные продукты в современном мире выскочили благодаря именно удачному дизайну (художественному конструированию, интерфейсам взаимодействия с пользователем, эргономике), а не внутренней архитектуре или конструкции.
И, кстати, меня не интересует Ваше мнение по поводу инкапсуляции. Вы просили объяснить, я объяснил. Если беседа перешла в разряд «я не согласен», значит Вы не спрашиваете, а спорите. Спор с узколобым пониманием определения инкапсуляции в языке программирования из википедии мне не интересен.
Ну і тому я думою що повинні бути й в візуалі бути якісь зручності з цього приводу.
Где-то прочитал что обычно люди спорят о том в чем они меньше всего разбираются
На этой фразе можно лишь сказать «занавес» в этом театре абсурда...
Наследование — частный случай инкапсуляции, когда инкапсулируется целиком класс, а не отдельные поля
А модифицированный мной пример про TDocument Вы не читали, не поняли или проигнорировали как неудобный?
Твой пример как на мой скромный быдлокодерский взгляд задизайнен неудачно (вообще дизайн — далекио неточная наука, и содержит элемент исковства, но этот конкретный пример я бы задизайнил по другому), и я не согласен что то что ты там называешь инкапсуляцией, ей является.
Там популярно разжовывается понятие инкапсуляции и её применение при проектировании.
А я спрашивал Софт (а не тебя) о понятии архитектурной инкапсуляции!
том числе на этот. Почитайте, в самом деле. Именно эта книга весьма интересна и очень легко читается.
Как то не нашел. Ну и я больше доверяю мнениям Буча и Страуструпа.
Но это все равно не обьясняет где в твоем примере инкапсуляция, и как она заменяет наследование.
А модифицированный мной пример про TDocument Вы не читали, не поняли или проигнорировали как неудобный?
Я Вам дал ссылку на авторитетную книгу, где популярно разжовывается эта концепция. Проявите интерес, почитайте.Там вводится понятие архитектурной инкапсуляции?
Там популярно разжовывается понятие инкапсуляции и её применение при проектировании.
Википедия — неавторитетный источник.
Но в ней есть ссылки на авторитетные источники.
В том числе на этот. Почитайте, в самом деле. Именно эта книга весьма интересна и очень легко читается.
Обычный С, не С++ и объекты ядра в kernel-development. Где объектом выступает структура данных которая однозначно определяет объект и его свойства, а поля которые не для изменений откоментированны в документации. В данном случае принципы ООП контролирует не компилятор, а программист.
Ок, я согласен, что неформально такая мысль имеет право на существование, но формально это не язык позволяет такое устроить, а процесс документирования и использования только документированной функциональности.
Ну вот здесь я не увидел инкапсуляции. Полиморфизм может быть (для разных типов дескрипторов вызывается разная логика). Но инкапсуляция возможно появится если упомянуть что данные и логика работы с дескрипторами находятся за слоем kernel API, и не может вызвана из user space минуя системные вызовы ядра, то есть скрыта от програмиста. Но это опять же очень неформальный подход.Например объект FDO файловой системы определяет параметры функционального устройства и содержит ссылки на таблицы устройства, например открытых файлов и дескрипторов кеша для каждого файла. В данном случае при той же операции записи в файл код по имени находит нужный дескриптор и работает с ним
Но это все равно не обьясняет где в твоем примере инкапсуляция, и как она заменяет наследование.
Паря 12 мин. назадОбычный С, не С++ и объекты ядра в kernel-development. Где объектом выступает структура данных которая однозначно определяет объект и его свойства, а поля которые не для изменений откоментированны в документации. В данном случае принципы ООП контролирует не компилятор, а программист.
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Я не видел ни одного процедурного языка который бы позволял делать такие штуки, может подскажеш?
Например объект FDO файловой системы определяет параметры функционального устройства и содержит ссылки на таблицы устройства, например открытых файлов и дескрипторов кеша для каждого файла. В данном случае при той же операции записи в файл код по имени находит нужный дескриптор и работает с ним.
Я Вам дал ссылку на авторитетную книгу, где популярно разжовывается эта концепция. Проявите интерес, почитайте.
Там вводится понятие архитектурной инкапсуляции?
Википедия — неавторитетный источник.
Но в ней есть ссылки на авторитетные источники.
Можно дать ссылки на авторитетные источники с обьяснением этого термина?
Я Вам дал ссылку на авторитетную книгу, где популярно разжовывается эта концепция. Проявите интерес, почитайте.
Согласно википедии...
Википедия — неавторитетный источник.
А вы не объясняйте. Программистом сейчас почти нет, есть быдлокодеры, а у них другой язык. И в отличие от уборщицы, полная уверенность в собственной непогрешимости.
Ах, да, Вы определенно правы. Как это ни странно звучит, быдлокодеров и среди аналитиков валом. Мне такой заявлял «я задокументирую за заказчиком всё, что он говорил, дам на подпись, а после реализации этих требований пусть не говорит, что программа не устраивает» — чистейший быдлокодинг требований.
Поэтому говорите с людьми на понятном им языке.
Я так и делаю — называю своими именами то, что вижу:)
троллей не кормлю
Вот так всегда, доходит до конкретики, и велокие архитекторы не могут снизойти до моей скромной персоны.
Там есть и инкапсуляция и наследование с точки зрения самого языка.WTF архитектурная инкапсуляция? Можно дать ссылки на авторитетные источники с обьяснением этого термина?Речь шла про архитектурную инкапсуляцию, которая разрабатывается еще до создания скелетов классов на каком-либо языке. В данном случае архитектурная инкапсуляция возможна даже на чисто процедурных языках, так как это не функционал языка, а логическое соглашение.
Я не видел ни одного процедурного языка который бы позволял делать такие штуки, может подскажеш?
Как для уборщицы, понятно?
Паря 16 мин. назадТам есть и инкапсуляция и наследование с точки зрения самого языка.Ну так может ты мне ответишь на понятном мне быдлокодерском языке, не прячась за высокопарными разсуждениями, где в твоем примере произошла инкапсуляция и отказ от наследования?
Речь шла про архитектурную инкапсуляцию, которая разрабатывается еще до создания скелетов классов на каком-либо языке. В данном случае архитектурная инкапсуляция возможна даже на чисто процедурных языках, так как это не функционал языка, а логическое соглашение.
А вы не объясняйте. Программистом сейчас почти нет, есть быдлокодеры, а у них другой язык. И в отличие от уборщицы, полная уверенность в собственной непогрешимости.Поэтому говорите с людьми на понятном им языке.
Ну так может ты мне ответишь на понятном мне быдлокодерском языке, не прячась за высокопарными разсуждениями, где в твоем примере произошла инкапсуляция и отказ от наследования?
Василий Чобиток 2 мин. назадА вы не объясняйте. Программистом сейчас почти нет, есть быдлокодеры, а у них другой язык. И в отличие от уборщицы, полная уверенность в собственной непогрешимости.
2 Soft:Ну что получилось уборщице?; -)) Поверьте, я после КВТИУ бойцам «от сохи» весьма сложные вещи объяснял, не говоря уже про юристов.
Поэтому говорите с людьми на понятном им языке.
Ну что получилось уборщице?; -)) Поверьте, я после КВТИУ бойцам «от сохи» весьма сложные вещи объяснял, не говоря уже про юристов. Просто здесь не ожидал наткнуться на столь глубокую дремучесть, поэтому, извините, сразу как-то и не попытался объяснять «как для уборщицы».
А по сути ответить как обычно слабо, ну-ну.
2 Soft:Ну вот кроме очень спорной модификации иерархии классов не увидел здесь никакой замены наследования на инкапсуляцию.
Ну что получилось уборщице?; -)) Поверьте, я после КВТИУ бойцам «от сохи» весьма сложные вещи объяснял, не говоря уже про юристов. Просто здесь не ожидал наткнуться на столь глубокую дремучесть, поэтому, извините, сразу как-то и не попытался объяснять «как для уборщицы».
оймите, кроме инкапсуляции на конкретном уровне OOP есть инкапсуляция на более высоких уровнях OOD и OOA.
Жесть, горе орхетектор-теоретег детектед.
Вы что?! При чём тут я?!Замените «инкапсулировали» на «упаковали функционал» и всё будет понятно. Просто вы пытаетесь известному термину определить новое определение.
«Инкапсулировать изменчивую часть» — это классика, это не я известному термину новое значение придумал, это к классикам. Поймите, кроме инкапсуляции на конкретном уровне OOP есть инкапсуляция на более высоких уровнях OOD и OOA. При этом, применение инкапсуляции на уровне анализа совершенно не зависит от того есть ли в языке программирования вообще возможности объявлять видимость свойств и методов классов и является ли вообще язык объектно-ориентированным.
Пример: фабрика классов для открытия разных документов.
Есть мастер-класс TDocument от него напрямую наследуются TTXTDocument, TWordDocument, TRtfDocument, вместо того чтобы TWordDocument, TRtfDocument наследовать от TTXTDocument.Так что здесь используется и наследование и инкапсуляция. Но в первом случае кроме инкапсуляции в стандартном понимании этого термина идёт упаковка функционала вместо размазывания его по куче наследников.
Ну вот кроме очень спорной модификации иерархии классов не увидел здесь никакой замены наследования на инкапсуляцию.
С семантической парадигмой что-то не то, в совокупности не совсем понятно...
Все нормально с семантической парадигмой, просто в КПИ заставляют мысли выражать простым, лаконичным и тривиальным языком. Учили, что если вы не можете рассказать как функционирует ваши алгоритмы обычной уборщице, то вы сами особо в этом не разбираетесь.
Пример: фабрика классов для открытия разных документов.прошу пример, который показывает как наследование заменяется инкапсуляцией
Так что здесь используется и наследование и инкапсуляция. Но в первом случае кроме инкапсуляции в стандартном понимании этого термина идёт упаковка функционала вместо размазывания его по куче наследников.
2 Soft:
Попробую этот хороший совет обратить к Вам.Просто отвяжите вашу семантическую парадигму от well known words, иначе все слова понятны, но в совокупности неясно что ими хотел сказать автор.
Цитата 1:
Это ж надо, такую ахинею с таким умным лицом несёт!
Цитата 2:
Иными словами, в упомянутой технологии Вы использовали ту ахинею которую я нёс с таким умным лицом?;:)Нет я как раз понял что вы сказали и использовал это в технологии...
С семантической парадигмой что-то не то, в совокупности не совсем понятно...
мы вынесли изменчивую часть за скобки — инкапсулировалиЗамените «инкапсулировали» на «упаковали функционал» и всё будет понятно. Просто вы пытаетесь известному термину определить новое определение.
Так как под инкапсуляцией здесь понимается не инкапсуляция полей объекта, а (инкапсуляция кода + полей) или определённого процессинга.
2Паря — чем проще и доступнее может человек обьяснить предмет — тем лучше он в нем разбираеться, так как любая сложная вещь уходит корнями в фундаментальные понятия
Вот вот, как бы появляются подозрения.
Чем Вас не устроил этот пример?
Мне несложно привести примеров. Но для адекватности примера следует знать уровень подготовки аудитории. Сходу привел шаблон Стратегия — аудитория не воспринимает...
Ну, ладно, попытка № 2: см. пример по ссылке (первые разделы можете смело пропустить и см. Часть 3. Программная реализация). Будет непонятно — сообщите, попробую что-нибудь на элементарном уровне.В примере использован шаблон проектирования Стратегия. При этом, применяя некоторые особенности языка PHP, к классу distribution подключаются конкретные алгоритмы распределения вообще без объявления абстрактного алгоритма распределения. Вот так, при появлении новых (изменении старых) требований, вместо того, чтобы плодить наследников от класса distribution, мы вынесли изменчивую часть за скобки — инкапсулировали.
Отлично, я на фразу
При появлении нового функционала они без зазрения совести наследуются, хотя правильно было бы инкапсулировать.
прошу пример, который показывает как наследование заменяется инкапсуляцией, а получаю пример где вполне себе мирно используется наследование, да еще и не используется инкапсуляция, логика зашкаливает...
В примере использован шаблон проектирования Стратегия. При этом, применяя некоторые особенности языка PHP, к классу distribution подключаются конкретные алгоритмы распределения вообще без объявления абстрактного алгоритма распределения. Вот так, при появлении новых (изменении старых) требований, вместо того, чтобы плодить наследников от класса distribution, мы вынесли изменчивую часть за скобки — инкапсулировали.
2Паря — чем проще и доступнее может человек обьяснить предмет — тем лучше он в нем разбираеться, так как любая сложная вещь уходит корнями в фундаментальные понятия
Паря 7 мин. назадТам все просто. Просто в тексте говорилось совсем не о том что было сказано.Ох уж эти горе-архитекторы — спрашываешь привести простенький примерчик, и попадаешь под град заумных терминов и отсыланию к толстым книгам.
Чуть похоже на антипаттерн «божественный-модуль», но содержит не весь функционал системы, а только тот, который логически неделим в рамках определённого процесса.
Ох уж эти горе-архитекторы — спрашываешь привести простенький примерчик, и попадаешь под град заумных терминов и отсыланию к толстым книгам.
Василий Чобиток 21 мин. назадНет я как раз понял что вы сказали и использовал это в технологии скрин-рендеров, где функционал рендера визуального объекта упакован внутрь класса. Так что изменяя рендер можем получить на базе той же кнопки или таблицы совершенно другое отображение, там где недостаточно только изменение свойств рендера.
2 Soft: по сути сказанного в последнем абзаце Вы правы. Но Вы таки не поняли сказанное мной (впрочем, формат кратких реплик не позволяет адекватно «раскрыть тему»), поэтому сделали неверные выводы.Попробуйте почитать упомянутую мной книгу А. Шаллоуея.
Просто отвяжите вашу семантическую парадигму от well known words, иначе все слова понятны, но в совокупности неясно что ими хотел сказать автор.
Попробуйте почитать упомянутую мной книгу А. Шаллоуея.
Ну почему же. Делал свои фреймворки вплоть до аналога XAML, пришлось расковырять VCL.Извините за нескромный вопрос. Я так понимаю, что Вы в Delphi дальше палитры компонент и лабания формочек не пошли?
Инкапсуляция — по сути упаковка функционала внутрь неделимого объекта. А наследование здесь вообще ни причем. Оно может как использоваться так и нет. Но к инкапсуляции оно никаким боком не лежало.
Не можете вести дискуссию, зачем троллить?Это ж надо, такую ахинею с таким умным лицом несёт!
Извините за нескромный вопрос. Я так понимаю, что Вы в Delphi дальше палитры компонент и лабания формочек не пошли?
Я дал ссылку на пример шаблона проектирования Стратегия. Вообще многие шаблоны проектирования построены на использовании инкапсуляции вместо наследования.Если вы понимаете, что требования неизбежно изменчивы, в том числе и на поздних стадиях проекта, то должны понимать, что в ранее написанный код будут вноситься изменения. Есть два способа на этапе проектирования предусмотреть будущие изменения: изменять реализацию классов путём наследования или инкапсулировать изменчивую часть. Конкретный пример для шаблона Адаптер. Абстрактный класс DB не только вводит единую спецификацию доступа к базе данных, но и инкапсулирует изменчивую часть от основной системы — при переходе на новую СУБД основная система не затрагивается вообще.
Это ж надо, такую ахинею с таким умным лицом несёт!
Просто в этой фразе
При появлении нового функционала они без зазрения совести наследуются, хотя правильно было бы инкапсулировать
звучит будто бы наследование и инкапсуляция — взаимоисключающие вещи, что выглядит странно.
Цитата:
Инкапсуляция — это не просто сокрытие данных. Такое слишком узкое представление ограничивает возможности проектировщика.Инкапсуляцию следует понимать как «любой вид сокрытия». Другими словами, это механизм, способный скрывать данные. Но этот же механизм может использоваться для сокрытия реализации, порожденных классов и много другого.
Ну в приведенном примере инкапсуляция отлично уживается с наследованием, не понял примера.
Я дал ссылку на пример шаблона проектирования Стратегия. Вообще многие шаблоны проектирования построены на использовании инкапсуляции вместо наследования.Дык, а что конкретно плохого в наследовании, и чем инкапсуляция принципиально лучше, можно короткий вменяемый пример?
Если вы понимаете, что требования неизбежно изменчивы, в том числе и на поздних стадиях проекта, то должны понимать, что в ранее написанный код будут вноситься изменения. Есть два способа на этапе проектирования предусмотреть будущие изменения: изменять реализацию классов путём наследования или инкапсулировать изменчивую часть. Конкретный пример для шаблона Адаптер. Абстрактный класс DB не только вводит единую спецификацию доступа к базе данных, но и инкапсулирует изменчивую часть от основной системы — при переходе на новую СУБД основная система не затрагивается вообще.
Дык, а что конкретно плохого в наследовании, и чем инкапсуляция принципиально лучше, можно короткий вменяемый пример?
Помоему сообщество «Делфи Мастерс» стоит переименовать в «Фрунзе»...
Я о том, чего катастрофически не хватает многим кодерам — понимания пройденного при обучении или прочтённого в Википедии. При появлении нового функционала они без зазрения совести наследуются, хотя правильно было бы инкапсулировать. Не в узком смысле приведенного определения инкапсуляции в языке программирования, а на уровне анализа и проектирования.Штопор лучше отвертки, двери дыр, а в природе всего есть определение ничего? Дайте еще пыхнуть, мистер Андерсон. Вы о чем?
Если Вы под инкапсуляцией понимаете только объявление приватных методов, для кодера это не страшно и нормально. Но такое понимание недопустимо для аналитика и архитектора.
Василий Чобиток 5 мин. назад
Золотые слова!А еще при прочих равных условиях инкапсуляция предпочтительнее и обычного немножественного наследования.
Штопор лучше отвертки, двери дыр, а в природе всего есть определение ничего? Дайте еще пыхнуть, мистер Андерсон. Вы о чем?
Инкапсуля́ция — свойство языка программирования, позволяющее объединить и защитить данные и код в объект и скрыть реализацию объекта от пользователя (прикладного программиста). При этом пользователю предоставляется только спецификация (интерфейс) объекта.
Золотые слова!А множественное наследование прекрасно заменяется инкапсуляцией вместо неоднозначностей.
А еще при прочих равных условиях инкапсуляция предпочтительнее и обычного немножественного наследования.
А динамическое выделение памяти это четвертый принцип ООП?
Нет, это одно из правил kernel-development, не загаживай стек. Если создавать кучу объектов на стеке можно и вылететь в синий экран.
А плавающую точку в обработчиках прерываний?
В Passive Mode IRQL использую, там нет никакой магии, всё расписано.
Кстати, а эксепшены вы часом в коде ядра не используете?
Я их и в своём обычном коде стараюсь не использовать, проще через передачу статуса выполнения функции. Хотя есть реализация для Passive Mode библиотеки STL, там и екзепшены есть.
А динамическое выделение памяти это четвертый принцип ООП?Потому что основной смысл ООП сделать сложность всей системы не выше максимальной сложности объекта используемого в системе.
А плавающую точку в обработчиках прерываний?
eugene_n 3 мин. назадПотому что основной смысл ООП сделать сложность всей системы не выше максимальной сложности объекта используемого в системе.А зачем?
А так вообще нафиг не надо. Кто пишет не на чистом асме — ламер мастайный непингуемый. А всякие Java/.NET программисты не программисты даже, а конфигурасты фреймворков.
Вот создайте этот класс выделив под него память в нестраничном пуле без перегрузки оператора new
А зачем?
Вот создайте этот класс выделив под него память в нестраничном пуле без перегрузки оператора new
class CMyClass {
public:
CMyClass () {;};
protected:int i; };
eugene_n 1 мин. назад
Да, не представляю как этой функцией в С++ выделить память под объект.В ядре?
Да.
Да, не представляю как этой функцией в С++ выделить память под объект.
В ядре?
В Delphi для этого нужно перегружать функцию NewInstance. Суть та же.
А если бы это был не оператор new, а вызов функции MyIncredibleMalloc () в логике программы что-нибудь бы изменилось?
Да, не представляю как этой функцией в С++ выделить память под объект.
А если бы это был не оператор new, а вызов функции MyIncredibleMalloc () в логике программы что-нибудь бы изменилось?
eugene_n 15 мин. назадА new/delete это по вашему что? В стандарте языка это операторы.
Вижу комплект оберток вокруг ExAllocatePoolWithTag / ExFreePoolWithTag.
Не вижу необходимости делать для этого перезагрузку операторов.
И вообще как без этой перегрузки выделить память в нестраничной области памяти под объект класса. Или вы сейчас начнёте говорить нафиг там клаcсы?
Не вижу необходимости делать для этого перезагрузку операторов.Ну как же, крутой пацан-крестовик просто обязан наперегружать операторов, создать несколько ненужный иерархий классов, обязательно применить паттерны (где надо и не надо), а для подтверждения своей полной крутизны продемонстрировать знания Александреску написать пару-тройку хитробы! баных шаблонов.
Это такая форма фаллометрии (теперь уже ретрофаллометрии из девяностых).
Не вижу необходимости делать для этого перезагрузку операторов.
А с этого места можно подробнее?
Повернись Живим
anonymous
Alexandr Gavriluk
Bogdan Shyiak
vasiliy chobitok
Андрей
svini
crypto5
#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 час назадВ некоторых случаях перегузка операторов очень удобна, например при разработке драйверов режима ядра просто необходимо перегружать new/delete причем иногда приходится делать специальные перегрузки этих операторов для определенных классов для использования страничной и нестраничной памяти. Для векторно-матричных библиотек тоже довольно удобно.
2 silverwolfУважаемый, киньте ссылочку, где С++ пахнет. Честно говоря, даже САМ Страуструп говорил, что надо было без перегрузки операторов и множественного наследования
А то же множественное наследование есть и в Java, и в Delphi, и в C# в той форме в которой оно тоже просто необходимо — в виде интерфейсов. А Труп Штрауса был очень ленив чтобы сделать в С++ по человечески.
Камень не помню, железо не я делал, камень поддерживал систему команд MSC52 (расширенный MSC51). Мне было этого вполне достаточно + протоколы общения с периферией.Название камня в студию.
Просто сейчас даже для kernel-drivers стараюсь использовать С++, так как удобнее. Если не особо шаманить с наворотами С++ типа темплейтов, конструкторов копирования (использовать объекты только через ссылку или указатель), не особо увлекаться многоуровневым множественным наследованием с виртуальными функциями, то по скорости и надёжности не отличается от обычного С.
Уважаемый, киньте ссылочку, где С++ пахнет. Честно говоря, даже САМ Страуструп говорил, что надо было без перегрузки операторов и множественного наследования
Ой...такой срач пропустил...как я мог...
Название камня в студию. И еще название среды разработки.Некоторое время писал на С++ под MSC51
Мне кажется вы немного преувеличиваете.
В общем да, кооперативная многозадачность. Преимущества в простоте реализации ОС и её малом размере.Не обижайтесь, но у меня складывается мнение что вы очень смутно представляете себе то, о чем пытаетесь рассуждать.
Когда на чипе 4K памяти ОЗУ, то размер ОС имеет значение.
Многие для embedded пишут свою собственную ОС. Из преимуществ этого подхода: объем ОС около 2 Кб, корпоративный параллелизм и использование только того что нужно.То ты embed’а не нюхал...
Некоторое время писал на С++ под MSC51, но да, особо не работал. Основное моё направление разработка системного ПО под Win32/Win64 и различные интеграции системной части кода с другими проектами.
Еще одна неплохая попытка:)
Тоесть Вы конечно же в курсе перечисленных выше языков и сейчас выскажите аргументированное мнение о превосходстве крестиков на одными?
Хорошо, давайте заканчивать.
Да, давайте, не думаю что от Вас мы услышим что-то толковое.
Вот найдеться здесь хоть один программист на Жаве который смело выйдет вперед и честно скажет «да, я пишу просто корпоративную систему с несложной логикой»?
Сейчас не знаю, 3 года назад Я писал просто корпоративное приложение с 1 модулем сложной логики, остальное CRUD. Тогда моим «фетишем» был «логичный и структурированный код», а также стыдно вспомнить TDD.
А можно узнать что именно и как долго Вы на нем писали?
Как на основном языке (то есть, тот за который мне платили деньги) всего 1 год. Но понимать его удобства уже когда пару лет поработал с Java.
но с Вашим уровнем я дажене смею рассчитывать
Еще одна неплохая попытка:)
Тогда почему Вы активно продолжаете обсуждать со мной С++?
Хорошо, давайте заканчивать.
Эта фраза исключительно из желания нахамить, или есть действительно повод так считать?
Нет, я действительно считаю, что в этом треде Вы являетесь единственным вменяемым собеседником. Читая перлы корпоративно-паралельно-высконагруженных не знаешь смеяться или плакать. (плакать потому что стыдно за профессию)
Помоему в этой ветке никто не обсуждал «тогда», а все (кроме тебя) обсуждают «сейчас».
Для любителей «сейчас» я отписал несколько названий в прошлом посте. Но они никогда не получат высокого распространения по все тем же причинам: имплементации, библиотеки, готовые спецы.
Enterprise — не всегда «написание корпоративных систем с несложной логикой» бывают и высоконагруженные приложения со сложной логикой.
Вы знаете, последние годы слово «высоконагруженный» стало таки прямо фетишем точкаНЕТчиков и Жабакодеров. Типо «я не быдлокодер, моя система высоконагруженная! ». Вот найдеться здесь хоть один программист на Жаве который смело выйдет вперед и честно скажет «да, я пишу просто корпоративную систему с несложной логикой»?
Та в том то и дело что ЦПП — таки очень удобный инструмент, просто надо «уметь его готовить».А можно узнать что именно и как долго Вы на нем писали?
Повторяю еще раз (для особо высоконагруженных): есть значительно более интересные языки для моей области (BitC, Cyclone, новострой Go), но с Вашим уровнем я дажене смею рассчитывать что вы хотя бы слышали такие названия (да и фамилии Шапиро, Пайк, Томсон)
Тут обсуждается Delphi, а не C++
Тогда почему Вы активно продолжаете обсуждать со мной С++?
2anonymous
Хорошая попытка:) Java я выбрал сознательно (после некоторого времени работы с C++), при чем в основном по «философским» проблемам.Судя по тому что у вас в профиле сплошная жава и ынтырпрайз Вас уже «отсеяли», да?
Enterprise — не всегда «написание корпоративных систем с несложной логикой» бывают и высоконагруженные приложения со сложной логикой.
Та в том то и дело что ЦПП — таки очень удобный инструмент, просто надо «уметь его готовить».Вообще странная позиция, считать неудобство инструмента преимуществом...
Если есть желание обсудить смерть ЦПП — откройте отдельную тему, кстати у меня была где-то закладка с постов «ЦПП умер, но все еще пахнет» (или что-то в этом роде)
Тоесть вы с третьей попытки это таки поняли?
Эта фраза исключительно из желания нахамить, или есть действительно повод так считать?
Вот только когда то С++ совершенно не был «мажорной» платформой, да и в посудную лавку эмбеда такого слона запустили относительно недавно...
Помоему в этой ветке никто не обсуждал «тогда», а все (кроме тебя) обсуждают «сейчас».
платформы проигрывают по многим другим параметрам (комьюнити, библиотеки, средства разработки и т.д.)Тоесть вы с третьей попытки это таки поняли? Это хорошо, вы пока на первом месте среди участников треда.
Вот только когда то С++ совершенно не был «мажорной» платформой, да и в посудную лавку эмбеда такого слона запустили относительно недавно...
Для «быдлоформочек» есть QT.
Этот рынок у СРешетки никакой Кьют уже не отберет. А учитывая какими темпами новый владелец Кьюта Нокия про! бывает рынок смартфонов можно смело сделать ставку, что Кьют так и останется игрушкой КДЕшников.
Вопрос к спецам по.Net: Можно ли использовать C++ при работе с ASP.NET? Мне говорили что можно, но утверждать не буду.
Я не спец по по точкаНЕТ, но предположу что мэнэджед кресты можно использовать с АСПом. А еще можно бриться газонокосилкой... Вы мне доказываете удобство или теоретическую возможность? Вы не думаете, что уход крестиков из этой ниши имеет под собой реальные основания? (нет, не заговор ЗОГ)
Вот тут дилемма. Если необходима быстрая заменяемость (написание корпоративных систем с несложной логикой или «сайтиков» ), то это недостаток. Если необходимо необходимо построить качественное приложение, то сложность языка (сложность окружения, точнее) — это плюс, сложный язык (окружение) позволит отсеять «случайных людей».Судя по тому что у вас в профиле сплошная жава и ынтырпрайз Вас уже «отсеяли», да?
Вообще странная позиция, считать неудобство инструмента преимуществом...
Только почему вы его сравниваете с всякими жабами? Сравнивать стоит с тем же Паскалем (на котором в свое время немало написали под системы, значительно более ограниченные, чем 99 процентов современного эмбеда), Фортраном или с Адой.
Я сравниваю с тем в чем разбираюсь, в отношении остального доверяю публичным бенчмаркам. Ну и считаю некоректным сравнивать С++ с минорными платформами, всегда смотрел на первую десятку TIOBE, так как минорные платформы проигрывают по многим другим параметрам (комьюнити, библиотеки, средства разработки и т.д.)
Думаю отсутствие фич (например в джава куча ран тайм информации привязанной к каждому обьекту и которая потребляет память).Ого, я уже было оставил надежду увидеть в этом треде вменяемые мысли.:)
Только почему вы его сравниваете с всякими жабами? Сравнивать стоит с тем же Паскалем (на котором в свое время немало написали под системы, значительно более ограниченные, чем 99 процентов современного эмбеда), Фортраном или с Адой. В конечном итоге все решила обратная совместимость с Ц, победа Венды на десктопах и правильный пиар от дедушки Страуса (типо новый улучшенный Ц от самой АТнТ, в то время как ведущие сотрудники оной до сих пор всеми силами от С++ открещиваются (каламбур)).
Для «быдлоформочек» есть QT.Раскроете тему «хорошести» крестиков для написания инет магазина или быдлоформочки?
Вопрос к спецам по.Net: Можно ли использовать C++ при работе с ASP.NET? Мне говорили что можно, но утверждать не буду.
Вот тут дилемма. Если необходима быстрая заменяемость (написание корпоративных систем с несложной логикой или «сайтиков» ), то это недостаток. Если необходимо необходимо построить качественное приложение, то сложность языка (сложность окружения, точнее) — это плюс, сложный язык (окружение) позволит отсеять «случайных людей».высокая сложность освоения языка — это преимущество или недостаток для его коммерческого применения?
Небольшое напоминание: Тут обсуждается Delphi, а не C++.
Доргой эксперт, может вы изложите свое ценное мнение относительно того, какие фичи _языка_ (а не современных, шлифуемых десятилетиями реализаций) С++ делают его недосягаемым для конкурентов в области производительности и «оптимизации по ресурсам»?
Думаю отсутствие фич (например в джава куча ран тайм информации привязанной к каждому обьекту и которая потребляет память).
Все таки не только поэтому, но и потому что в плане производительности и оптимизации по ресурсам С/С++ нету конкурентов (ну кроме ассемблера)
Доргой эксперт, может вы изложите свое ценное мнение относительно того, какие фичи _языка_ (а не современных, шлифуемых десятилетиями реализаций) С++ делают его недосягаемым для конкурентов в области производительности и «оптимизации по ресурсам»?
На С++. Потому что нет альтернатив ему в некоторых областях. Не потому что язык хороший, а потому что готовые библиотеки, компиляторы под все разумные платформы и куча программистов с ним знакомых.
Все таки не только поэтому, но и потому что в плане производительности и оптимизации по ресурсам С/С++ нету конкурентов (ну кроме ассемблера)
C++ хорош абсолютно для всего (в этом его основное преимущество)
Раскроете тему «хорошести» крестиков для написания инет магазина или быдлоформочки?
вот только для того что бы с ним работать надо иметь довольно высокую подготовку.
Капитан очевидность, вы как всегда вовремя! Теперь вдумайтесь: высокая сложность освоения языка — это преимущество или недостаток для его коммерческого применения? (для возведения в объект надроча и поднятия ЧСВ однозначно плюс, только в этой области шаблоны и паттерны давно вытеснили замыкания и монады)
А на чём же вы пишите для ембедед. На Java?
На С++. Потому что нет альтернатив ему в некоторых областях. Не потому что язык хороший, а потому что готовые библиотеки, компиляторы под все разумные платформы и куча программистов с ним знакомых.
В общем да, кооперативная многозадачность. Преимущества в простоте реализации ОС и её малом размере.
Не обижайтесь, но у меня складывается мнение что вы очень смутно представляете себе то, о чем пытаетесь рассуждать.
Многие для embedded пишут свою собственную ОС. Из преимуществ этого подхода: объем ОС около 2 Кб, корпоративный параллелизм и использование только того что нужно.
То ты embed’а не нюхал...
Я Вам открою секрет: в 21 веке С++ как язык не хорошь вообще ни для чего,
C++ хорош абсолютно для всего (в этом его основное преимущество), вот только для того что бы с ним работать надо иметь довольно высокую подготовку.
Я Вам открою секрет: в 21 веке С++ как язык не хорошь вообще ни для чего, приходиться его использовать именно потому что есть высококачественные реализации и библиотеки. Делфи же на данный момент не хорош вообще ни в чем.А на чём же вы пишите для ембедед. На Java?
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 — установка фреймворка, то С++ хороша только для системного (там где и ниша этого языка была, есть, и будет), морду приложения все равно лучше делать на чем-то другом.
Где-то была библиотека для быстрой обработки строк на С++ с использованием фич SIMD, так вот там для char и wchar_t писали несколько отличающийся код.
вхворкс бизнес интересует только в качестве серверной средыНа тему ВхВокса как серверной среды тоже было бы интересно послушать.
Думаю такая тема заслуживает написание как минимум кандидатской!
Кстати, в банках еще можно встретить софт на DBase, который продолжает развиваться местными программистами-админами в одном лице.:)
Это 5! Ты сделал мой день. Особенно порадовала каша в голове где эксперт путает ананимные функции, замыкания и почему то называет все это эвентом. Наверное потому что на обработчики событий удобно биндить анонимные функции и замыкания?
Дорого формошлеп, что бы на твоем компьютере вообще что-то крутилось внутри него надо запрограммировать контроллер жесткого диска, сетевую карту, вайфай адаптер и кучу чего еще, где часто используются РТОС типо ВхВоркс.
А вот отсутствие виртуальных конструкторов в С++ и анонимных замыканий (events) делают особо муторной реализацию в С++ некоторых паттернов про реализацию которых в Delphi даже не думаешь, оно в самом стандарте языка.
Это 5! Ты сделал мой день. Особенно порадовала каша в голове где эксперт путает ананимные функции, замыкания и почему то называет все это эвентом. Наверное потому что на обработчики событий удобно биндить анонимные функции и замыкания?
А вот шаблоны не нравятся по причине неэффективной генерации кода, так как нельзя оптимизировать код под тип данных.
Дорогой эксперт, можете пожалуйста развить мысль?:)
anonymous 24 мин. назадИ еще вопрос коллективу анабиозных адептов делфи из далекого почти забытого прошлого: где скачать компилятор делфи для интересующих лично меня платформ — линукс, макос и вхворкс.
Программы на Делфи работают на 90% десктопов мира. А 10% линукс, макос и вхворкс бизнес интересует только в качестве серверной среды или в случае макос — для гикнутых дизайнеров.
Перегруженный оператор ничем, так как по сути та же самая функция. И не вижу необходимости в операторах, когда можно использовать функцию.Дорогой делфимастер, расскажите пожалуйста чем по Вашему авторитетному мнению вызов перегруженого оператора отличается от вызова функции?
А вот шаблоны не нравятся по причине неэффективной генерации кода, так как нельзя оптимизировать код под тип данных.
Кроме того всякая перегрузка операторов и шаблоны выроджают скорость работы C++ программ до скорости.NET.Дорогой делфимастер, расскажите пожалуйста чем по Вашему авторитетному мнению вызов перегруженого оператора отличается от вызова функции?
А заодно, как именно шаблоны убивают производительность; -)
И еще вопрос коллективу анабиозных адептов делфи из далекого почти забытого прошлого: где скачать компилятор делфи для интересующих лично меня платформ — линукс, макос и вхворкс.
Кроме того всякая перегрузка операторов и шаблоны выроджают скорость работы C++ программ до скорости.NET.
Дорогой делфимастер, расскажите пожалуйста чем по Вашему авторитетному мнению вызов перегруженого оператора отличается от вызова функции?
Че правда? В C есть перегрузку операторов, шаблоны?
Не обращая внимание, это гость из середины девяностых... Разморозили видимо недавно.
silverwolf 8 мин. назадЗато в С++ нет GUI с коробки. Конечно есть QT и wxWidgets, но их нужно прикручивать. MFC это вообще бред сумасшедшего, почему же сейчас на С++ под Windows GUI уже не пишут.Че правда? В C есть перегрузку операторов, шаблоны?
Кроме того всякая перегрузка операторов и шаблоны выроджают скорость работы 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 после борланда?
Кстати, 15 июня будет проводиться бесплатный семинар «Embarcadero: профессиональные инструменты разработки приложений и баз данных»
Знакомый работает на COBOL! И че? Теперь все забиваем на Java/C# и учим COBOL?
COBOL разрабатывался специально для бизнес проектов так что можно и выучить. А делфи это среда разработки и сейчас медленно подыхает.
Не совсем по теме, как именно роботает этот код? Или автор в ЕХЕ-шку вирус залил, как узнать?
Знакомый работает адвокатом. Все брысь в Могилянку получать второе ВО.
Вполне себе мейнстримные вещи делаются на Дельфи. Вообщем, изучать есть смысл.
Че все по новой? Не могли бы вы подтвердить свое имхо реальными фактами.
В банках используется Delphi!
Знакомый работает на COBOL! И че? Теперь все забиваем на Java/C# и учим COBOL?
В банках используется Delphi!
И не только в банках. Вполне себе мейнстримные вещи делаются на Дельфи. Вообщем, изучать есть смысл.
В банках используется Delphi!
maximus:
object-pascal / C++ / Object-C / C# / Жаба и пр. — это IMHO в данном вопросе не важно.всё тот же Borland выпустил С++Builder. такая же IDE, только вместо object pascalя Сшный код. вот и используйте, кому нравится IDE. ещё и еxe’шник в 2 раза меньше., а паскаль удобен для изучения программирования с нуля
А сами же двинемся дальше не оглядываясь на прошлое:)
Сшный код. вот и используйте, кому нравится IDE. ещё и еxe’шник в 2 раза меньше
Билдеровский компилятор сосал еще у тогдашнего gcc, а сейчас тем более. Плюс практическое отсутствие готовых компонентов, нежно любимых б-кодерами и программистами-любителями.
всё тот же Borland выпустил С++Builder. такая же IDE, только вместо object pascal
Mike Gorchak
Sergii Voloshyn
Valentyn K
я Сшный код. вот и используйте, кому нравится IDE. ещё и еxe’шник в 2 раза меньше., а паскаль удобен для изучения программирования с нуля.
Andrew:
Я там вказав, як я працюю з портами вводу виводуAndrew, в серьезном проекте я бы за
Це дуже просто, так як завжди було у всіх версіях Делфі і на асемблері
in al, 123Раніше не знав, що можна через CreateFile ()
А что же касается оптимизации самого языка, то конечный вариант уже x86 ассемблерного кода (не MSIL) cгенерированного из С# программы не хуже, а то и лучше, чем Delphi. Мы когда переползали на C# ставили такие эксперименты и сравнивали конечный ассемблерный код и качество этого кода нас очень и очень удовлетворило.
А Java i C# — це для дітей, які в програмуванні нічого, крім малювання формочок не бачили:)Честно говоря, тоже так думал.пару-тройку лет тому назад, пока не пересел на C#:)Особливо C# — це для особливо малих дітей, які не бачили, що сталось із програмістами, котрі присвятили свої кращі роки вивченню технологій Майкрософта.:)
В Дельфях одна гниль только и осталась
И ВУЗы, в которых это «преподают».
Гвоздь номер 2.
Ниша номер два — студенты, которым главное — побыстрее слепить лабу/курсач.
Из собственного опыта, на.Net для начинающего слепить что-то на завтра намного быстрее чем на Delphi, и синтаксис у С# — больше похож на Java:)
Ниша названа — АСУ ТП на небольших пост-совецкий заводах, где требуеться не высокая стоимость и не требуеться высокое качество разработкиЕсли других нет, то предлагаю начать заколачивать гроб
Ниша номер два — студенты, которым главное — побыстрее слепить лабу/курсач. И ВУЗы, в которых это «преподают».
Don’t you see that the author is Delphi-only guy? Leave him alone.
* ___ c_c_c_C/ \C_c_c_c____________
in al, 123
mov voltage, al
Будь-ласка аналогічний код С# в студію!
Я не шарю в С#, но для Java я очевидно напишу за часик в раслабленном режиме функцию на С, которая предоставит мне такой вот интерфейс:
int voltage = PortHelper.readFromPort(123);Я не вижу в этом киллер фичи.
Короче надо закопать делфи и никому не показывать.
Ниша названа — АСУ ТП на небольших пост-совецкий заводах, где требуеться не высокая стоимость и не требуеться высокое качество разработки
Если других нет, то предлагаю начать заколачивать гроб
Постараюсь продовжити в понеділок.
Ні junior_dev, проблема не в тому, що я не розказав Вам щось про драйвер.приведеный вами пример асемблерного кода не являеться фичей Delphi вы так же его можете скопилировать и подключить в С#, он умеет работать с UnManaged DLL если интерескак см примеры выше для Win API.
Проблема в тому, що Делфі може працювати з портами вводу-виводу, а C# не може.
Visual Studio так же позволяет дебажить в x32 managed & unmanaged код одновремено, так что это возможно в C#
не требуеться высокое качество — дабы не обидеть собеседника взято из того что народ готов жить с мнимым реальным временем на продуктах которые не поддерживаються (WinXP уже не поддерживаеться МСом насколько я знаю).
Аргумент, он этого не умеет потому что я не знаю как, а вам не скажу что, конечно убойный и тут ничего не возразишь:), но зато хорошо характеризируетjunior_dev, я вже 4 рази сказав як я це роблю. Це дуже просто.
У всіх інших випадках я працював без ніякого драйвера. І знання драйвера не потрібно взагалі. Навіть якщо його використовувати. Він просто запускається і знімає обмеження, які є в WindowsXP Програма ніяк з ним не взаємодіє.
если у вас есть драйвер с интерфейсом в User mode — то его можно использовать в C# так же как вы его используете в Delphi, так как я не знаю вашего драйвера я вам не могу код привести...Ні junior_dev, проблема не в тому, що я не розказав Вам щось про драйвер.
Проблема в тому, що Делфі може працювати з портами вводу-виводу, а C# не може.
Кста для тег кто видел сначала Си подобные языки, а потом паскаль (делфи) он тож кажется убогим?
мне интересно знать, что именно вам удобно сам паскаль, или делфовская иде?
просто мені і багатьом іншим на Delphi зручніше.
Не хочу вас огорчать, но не “багатьом”, а “декільком”. Из моих знакомых кто заканчивал ВУЗ в последние 4 года, только один человек работал на Delphi, и то через год перешел на другой язык.
Для каких задач?Якщо є кращі — я хочу про них знати.
Вы можете четко описать нишу Delphi?
Ні, просто мені і багатьом іншим на Delphi зручніше.вы хотите сказать что ваше АСУ строиться на этих уникальных особеностях Delphi?
Якщо є кращі — я хочу про них знати. Але без флейма.
Якщо ці зручності є, і в конкретній задачі себе виправдовують, то треба юзати відповідно іншу мову, а не Delphi.и все остальные удобства других языков не стоят этого?
Я вже про це сказав вище.
Тільки схоже, що сі-шарпу він не допомагає, бо в цієї мови немає деяких можливостей, які є в Делфі:)
пока что единственым вашим аргументом был in place асемблер, но вы можете этот код редактировать в студии и подключить в шарп
Аргумент, он этого не умеет потому что я не знаю как, а вам не скажу что, конечно убойный и тут ничего не возразишь:), но зато хорошо характеризирует
Драйвер окремий.В апартный порт писать без Kernel mode driver в NT ядре нельзя, или вы и драйвер в Delphi написали?
Пропоную на цьому закінчити.
В апартный порт писать без Kernel mode driver в NT ядре нельзя, или вы и драйвер в Delphi написали?
Кряк для ХР єЯ не знаю яке тут визначення «крякання».
І це нормально? Ліцензія забороняє вінду крякати, будь-яку частину. На крякнутому ядрі глючної ХР запустим АСУ — жесть!
Якщо я заставляю систему давати мені доступ до моїх власних потрів вводу-виводу, то це не є порущенням ліцензії
Точно не пам’ятаю, але достатньо впевнений, що ССЕ2 присутнє.А як там у Делфі-асма з ССЕ3?
Якщо чогось мало — можна на FPK переїхати, там повинно все бути
А з вирівнюванням в пам"яті? Усьо грає? Можна вручну то вказати? Бо буває треба деколи.На Делфі мені таке було треба тільки раз.
Конкретно в мене було дуже мало проблем з кодогенерацією, і я їх всіх пофіксав за допомогою перекомпіляції FPK.
support.microsoft.com/kb/115831 — вот вам пример:)Якщо це було звертання до мене з приводу портів, то ця сторінка тут взагалі ні до чого.
Схоже що дехто з тих, хто намагаються вчити мене, як правильно писати АСУ, так і не зрозумів різниці між апаратними портами вводу-виводу і СОМ-портами:)
Кряк для ХР є
І це нормально? Ліцензія забороняє вінду крякати, будь-яку частину. На крякнутому ядрі глючної ХР запустим АСУ — жесть!
ведь это более практичное в больших и сложных приложениях;) ведь к примеру можно построить АСУ так что бы добавляя новый девайс в систему без обновления основного кода:) не останавливая его в реальном времени
А з вирівнюванням в пам"яті? Усьо грає? Можна вручну то вказати? Бо буває треба деколи.
Таке хіба в
98-й вінді ще можна було писати. ХР пряме звернення до портів банить. Чи у вас є кряк на кернел?
Кряк для ХР є.
Код на Делфі — один рядокЦе код на Делфі.
in al, 123
Ты подтасовываешь: — по первых это не код на делфи (кто то тут сокрушался что ему тяжело учить два разных языка — с и java, а асемблер и паскаль это похожие языки?)
Вбудований асемблер — одна із переваг Делфі, про що я вже казав багато раз.
Ну почалося...— во вторых очевидно что одной строкой ты не ограничишься, тебе еще нужно будет записать значение в паскалевскую переменную.
Ото проблема- в змінну записати:)
in al, 123
mov voltage, al
Будь-ласка аналогічний код С# в студію!
+1 к Доценту насчет asm кода в NT ядре
in al, 123
Таке хіба в
Код на Делфі — один рядокin al, 123
Ты подтасовываешь: — по первых это не код на делфи (кто то тут сокрушался что ему тяжело учить два разных языка — с и java, а асемблер и паскаль это похожие языки?) — во вторых очевидно что одной строкой ты не ограничишься, тебе еще нужно будет записать значение в паскалевскую переменную.
Таймер реализован не Delphi, а ОС это ОС определяет частоту таймера:) я также вам привел ссылку на Win API функцию которая этот таймер создает...
Я її не помітив
in al, 123Я не помітив на цій сторінці пояснення, як працювати з апаратними портами вводу- виводу через CreateFile ()
Раніше не знав, що можна через CreateFile ()
Это обьясняет многое:) спасибо
Пример очень простой:)
Будь-ласка код на С#?
не очевидно, пожалуйста примедите замеры производительности и если возможно то логи профайла что программа работает из-за медленой обработки события, а не к примеру из-за скорости порта...
І взалалі — очевидно що в будь-якому разі, обробник таймера на Делфі буде відпрацьовувати швидше, ніж на C#.не очевидно
Таймер реализован не Delphi, а ОС это ОС определяет частоту таймера:) я также вам привел ссылку на Win API функцию которая этот таймер создает...
Я там вказав, як я працюю з портами вводу виводуЭто обьясняет многое:) спасибо
Це дуже просто, так як завжди було у всіх версіях Делфі і на асемблері
in al, 123
Раніше не знав, що можна через CreateFile ()
А можна деталі?Я тебе уже приводил пример SAP MES, такая же архитектура скажем и у HP-шной MES — Java на центральном сервере и C/C++ на контролиурющих девайсах.Особливо про технології і іїхні конкретні переваги перед Делфі?
Конечно такая архитектура стоит дороже, и при копеечных бюджетах вполне можно посмотреть на delphi, но за такой выбор можно отгрести в будущем.
Наскільки я пам’ятаю, в тих постах мова йшла про таймер, котрий базується на WM_TIMER.Ваш аргумент почему Delphi лучше C# — таймер — который API функция винды и реализован в.Net Framework 2
Просто констатую перевагу Делфі в конкретному випадку.
Я там вказав, як я працюю з портами вводу виводуПорты — с которыми вы в Delphi скорее всего работаете через API CreateFile function что тоже есть в C#
Можна приклад, як це робиться на C#?
вы готовы выкинуть поддержку, обновление, расширение, кучу приложений для эфективного и качесвеного кода итд... поэтому вопрос, неужели это ключевой момент в вашем АСУ?Я нічого не викидаю.
Я просто показав конкретні переваги.
На Delphi много написано, это надо поддерживать, поэтому еще некоторое время, какой-то спрос будет, но вот новые проекты мне не известны. АСУТП, о которых тут так много говорили, переписывать просто так никто не будет, поэтому они будут жить еще долго, но кучу всего на VB — тоже переписывать вряд ли будут, но это не делает VB «живым языком».
В принципі і звичайний масив можна розглядати як динамічнийЦе танці з бубном. А цілі числа довільної довжини і їх арифметика є з коробки в Делфі? Бо дивіться, як можна:
array_typt=array [1...1000] of integer
P=^array_type
getMem (P...)
тільки треба щоб фактичний розмір був менший ніж оголошений, або відключати перевірку індекса
Не згодиться вам таке в АСУ? Щоб про оверфлов не думати?
Є наприклад стандартний тип ТStrings, який дозволяє індексувати стрічкамиОт бачите, скільки мороки. І після цього ще говорять про Паскаль як наше всьо в структурах даних.
Наскільки я пам’ятаю, в FPK є ціла бібліотека для хеш таблиць.
Якщо треба щось інше, то можна оголосити свій клас, перевизначити постфіксний оператор індексації []
І описати, що там треба.
Або перетворювати в стрічку. І індексувати нею, використовуючи використовувати TStrings
А Делфі
если человек строит АСУ ТП на триках языка типа a [3, 7, 6] = 376 то это обьясняет многое в плане квалификации...
Можна взнати, що саме це пояснює?
До речі АСУТП тут взагалі ні до чого.
А тріків тут ніяких нема, це загальна формула обчислення офсета в масиві.
І судячи з того, як (зовсім неправильно) Ви її записали, вона Вам незрозуміла.
Ваш пост, 8я страница
Простий приклад
є тримірний масив a []
вираз a [3, 6, 7] може бути
1. оптимізований під час компіляції (тобто транслюється в щось типу a [367])
STL буде обчислювати вираз 3*100+6*10+7 в рантаймі, що буде повільніше
не понял, что будет медленее и зачем превращать его в число в 10ти значной системе?
Я мав на увазі, якщо розмір кожного виміру 10, то результуючий офсет буде 367.
вопрос, какое практическое применение использования такого офсета? потому что исходя из ваших доводов только одно отличие и в нем... и ради офсета вы готовы выкинуть поддержку, обновление, расширение, кучу приложений для эфективного и качесвеного кода итд... поэтому вопрос, неужели это ключевой момент в вашем АСУ?
на самом деле вам привели кучу примеров, просто вы их проигнорировали,
Я старався уважно читати все, що тут писали, але не помітив ні одного прикладу АСУТП на С#
А можна деталі?кстати я знаю как минимум 3 завода с АСУ построеным на приведеных выше технологиях,
Особливо про технології і іїхні конкретні переваги перед Делфі?
но это бесполезно,
Напевно у зв’язку з відсутністю змістовних аргументів.
если человек строит АСУ ТП на триках языка типа a [3, 7, 6] = 376 то это обьясняет многое в плане квалификации...Можна взнати, що саме це пояснює?
І судячи з того, як (зовсім неправильно) Ви її записали, вона Вам незрозуміла.
на заре своей работы я писал АСУ ТП для 3х заводов
На С#?
Я ніде не казав, що bottleneck кожного АСУ ТП обов’язково в перформансі., и помню что bottleneck там не в тех триках которые вы приводите...
Я просто приводив конкретні переваги Delphi перед C#.
Ви мене спалили:)вы знаете что такое профайлер?
Пішов на Вікіпедію, узнавати, що таке профайлер...
кстати, пресловутый перформанс Delphi в ваших примерах... на заре своей работы я писал АСУ ТП для 3х заводов, и помню что bottleneck там не в тех триках которые вы приводите... вы знаете что такое профайлер? вы хоть раз смотрели план выполнения?
Може мої екскурси в програмування апаратури на Делфі створили враження, що я пропоную відмовитись від контролерів взагалі і все перевести на десктоп:)але тут я наскільки розумію з ПК робиться промисловий комп"ютер, на яке вішається все — робота з фізичною апаратрою і бізнес логіка. Підхід досить специфічний. Я не зустрічав.
В цьому теж інколи є свій зміст, особливо для швидкого прототипування.
Вбудовані хещ-таблиці та функції хешування:Є наприклад стандартний тип ТStrings, який дозволяє індексувати стрічками
Для динамічних структур даних мені було зручніше писати на перлі/пітоні.
Не дуже зрозумів, який “аналогічний” тип требаА можно определить пользовательский тип данных, аналогичный массиву с изменяемым размером?
Type MyType=array of Inteher;
А в чому власне проблема?Покажіть мені таку структуру даних (масив з можливістю зміни розміру на льоту) в Паскалі. Як частину стандарту мови, а не лібу від дяді Миколи/Васі/Петі
тільки треба щоб фактичний розмір був менший ніж оголошений, або відключати перевірку індекса
А можно определить пользовательский тип данных, аналогичный массиву с изменяемым размером?
так і тут делфі бензину не просить і запряг і пашеш
Взагалі складно знайти мову з кращими структурами даних ніж Паскаль, або хоча б такими ж.Ай, дайте спокій. Ви зовсім як вуйко з села, що все життя їздить на возі і нічого іншого знати не бажає. Віз простий, коням сіна дав і вйо:)
Після цього поста я зрозумів, що далі нема чого балакати — ми один одного не переконаєм. Тому успіхів Вам в розробці АСУ на Делфі!:)
Але там, де цього досить — проблеми нема.
А тепер дивіться, як ці приклади з роками пишуться без хардкоду і зайвих багів:
flyman
(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
А ще є досить специфічні мови для ПЛК, тойже Степ5, наприклад
Але я б сказав проблема не з самим каном шиною, так як для ПК вона не є природною.Та невже? Скажіть будь ласка, де я можу знайти бібліотеку для, припустимо, роботи з CAN? Досить типова шина для промислової електроніки.
До дельфіна буде питання, так як зара езернет і КАН шина де факто стають польовими шинами в апаратурі, як ралізується робота з ними на Делфі?
for year=2000 to 2010 doЗгідний, що спочатку треба запам’ятати просте правило, в циклі for змінна проходить всі вказані значення включно (для більшості людей це напевно expected behaviour)
for (year=2000; year < =2010; year ++)
Смотря на второй код очевидны начало цикла (2000), условие окончания (< =2010) и шаг (+1)
Прочитав паскаль код очевидно начало цикла (2000), но вопрос про окончание цикла (необходимо знать что он работает как < =2010, а не < 2010), необходимо знать что в for используется шаг=1 (хотя это не сложно угадать).
Але в моїй практиці проблеми з цим були в мільйон раз менші ніж з неправильним розіменуванням складних структур даних.
А теперь вернемся к теме ошибок и гибкости. Как будет выглядеть на паскаль кодТреба буде писати циклом whilefor (year=2000; year < 2010; year = log (year))
Якщо до двох вимірів, то напевно це не критично.
бо вже є купа розроблених АСУЗ тих що я знаю — в основному на коліні, хоча сайти в деяких є (хто фірми).
Яка така купа? А можна сайти виробників, умови підтримки, ціни? Чи то всьо на колінці клепається і далі одного заводу не виходить?
А умови напевно кращі ніж в конкурентів, раз вони тримають більшу долю ринку.
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 віднімаєм... Так Вибидлокодермаєте поганий стиль програмування?
Відповідно є випадки, коли це створює проблеми аж до провалу проекту через зрив строків розробки.
Наприклад в АСУ Делфі здається в нас займає більшу нішу, ніж всі інші мови разомЯ ж кажу — підсіли люди в молодості, та й не годні зіскочити. А не боїтесь, що в компіляторі чи рантаймі бага якась вилізе? Хто вам на той делфі патч дасть? Сорсів-то нема, ага.
Я не вірю, що молодий випускник універу писатиме АСУ на Делфі.
Мені простосто ніколи не було треба — нагуглити готові бібліотеки для Делфі не проблема.
Та невже? Скажіть будь ласка, де я можу знайти бібліотеку для, припустимо, роботи з CAN? Досить типова шина для промислової електроніки.
В мене і на такий приклад часу особливо нема.Цей приклад просто показує, що на всякій мові можна писати неакуратно. Більше він нічого не показує.
Він розрахований на того, хто хоче вникнути і зрозуміти суть.
Те що там можна −1 забути, чи ще щось таке, то мало що можна забути чи не знати. Ніби на Делфі нема поганого коду — теж тулять там все в button.click, забуваючи про нормальне проектування. Благо ІДЕ сприяє.
DCB структура оголошена, якщо не помиляюся, у stddef.h Ви можете використовувати цей хідер у Делфі?А Ви про це...
І там як правило ще є приклади готових програм, то не треба розбиратись починаючи з нуля.
Дивлюсь я на цей код, і він мені не подобається. Прямо як лаба студентська, прости ГосподиДарованому коню в зуби не заглядають:)
Якщо бажання зрозуміти нема — ніякий приклад не поможе.
Вы привели очень интересный пример
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))
?
Я не агітую за Делфі.Або автор вузько спеціалізувався в АСУ, і трохи не ту мову в юності обрав. Писати про переваги Паскаля і Делфі в цій області трохи маргінально, не той калібр в цих засобів.
Напевно пояснення не дотягує до математичної теореми, але як вже вийшло.
Тобто ефективність мови програмування визначається ефективністю розробки коду, специфічного для конкретного АСУ, який не можна розробити окремо.Є критично важливі частини коду, які працюють з реальними механізмами, котрі рухаються в реальному часі.
STL тут абсолютно нічим не допоможе.Помоему это уже начался неадекватный бред. Откуда взялась идея разрабатывать код в риал тайме? Где это у вас так процесс построен?
Інші 99% можна розробити порівняно легко, хоча об’єм їх може бути і великий.
Я мав на увазі, що певні частини АСУ (неспецифічні для даного заводу) можна купити в готовому вигляді.«Тобто ефективність мови програмування визначається ефективністю розробки коду, специфічного для конкретного АСУ, який не можна розробити окремо.» — это вообще метафизика какая то...
А от специфічний для даного АСУ код, який не можна розробити окремо, це і є основна проблема.
\|||/ (o o) ,----ooO—(_)-------. | Please | | don’t feed the | | TROLL’s ! | ’--------------Ooo—’ |__|__| || || ooO Ooo
Я в АСУ ні разу не зустрічався з потребою в такому класі, але думаю, що готові реалізації для Делфі існують.Я нічого не екстраполюю.Ну значит у тебя были очень плоские алгоритмы, но не нужно свой опыт экстраполировать на всю отрасль!
Може в когось ситуація зворотня — нехай поділитиься.
Я как бы был одним из ее разработчиков, куда уж реальнее?...Мене взагалі-то більше цікавить досвід впровадження.
Часто виходить так, що тут розробити з нуля ефективніше, ніж там купляти і тут доробляти.
Зрозуміло, що є понтові закордоні системи, які декларують багато інсталяцій десь там.Конкретну розкручену але неефективну АСУ-систему привести не можу, але практика схиляє до висновку, що ефективнісь розробки і впровадження не знаходится ні в якому співвідношенні ні з ціною, ні з кількстю задекларованих інсталяцій за кордоном.
Але практика показує, що на це великої уваги звертати не треба.
При практичній перевірці на реальному нашому заводі вони можуть виявитися дуже неефективними.
Серия очень странных голословных утверждений.
Це не теоретичні гіпотези, а реальний досвід спілкування з різними продавцями всяких систем для заводів.
А сам STL зрештою не на елементи мови опирається? До них не зводиться? Які Ви знаєте взагалі методи оптимізації в компіляторах, окрім обчислення цих індексів школярських?
Приклад зі стелі. Він призначений для ілюстрації ідеї.Той приклад з масивами взятий зі стелі. Чи Ви генерований код читали?
Можна звичайно сподіватись на оптимізатор, але то не гарантований результат.
Я не бачу жодної причини казати що 3*100+6*10+7 піде в рантайм. І він таки не піде.
Можливо на даному конкретному прикладі і не піде, але взагалі швидкодія структур даних, описаних користувачем тільки в ідеальному випадку досягає швидкості нативних структур.
Як рішення проблеми пропонувався STL.Я мав на увазі, що наприклад нативні масиви зі статичними індексами оптимізуюься компілятором тривіально.
Але STL по функціональності не може повторити нативні типиПо якій функціональності? Чого бракує?
Чим складніша оптимізація потрібна, тим рідше і гірше вона буде спрацьовувати.
бо вже є купа розроблених АСУ
Яка така купа? А можна сайти виробників, умови підтримки, ціни? Чи то всьо на колінці клепається і далі одного заводу не виходить?
Я знаю багато прикладів обробки апаратури, написаних на Делфі.Я взагалі-то говорив про швидкодію в контексті обробки апаратури.
В мене нема теоретичного доведення, що на Фокспро це неможливо.
Але це не є підставою писати АСУ на Фокспро.
Набагато логічніше йти перевіреним шляхом.Мы ведь разговаривали про быстродействие и С#, а не проFoxPro и «обробку апаратури»?
А зручність і ефективність C# для даного класу задач — це фантазія, поки нічим не підверджена.
for (year=2000; year < =2010; year ++)LOL
for (month=1; month< =12; month++)
printf («year= %i month=%i result=%i», year, month, res_fuc (a [year-2000, month-1]))
Це вже не до мови питання — таке городити. Це вже загальна здатність до проектування програм.
Ты не уловил суть моего аргумента, на современных серверах 300 мб — это 1% памяти, то есть они влияют на свопинг приблизительно так же как и 1 мб.1. Я якраз і мав на увазі що ці логічні побудови в практиці не завжди працюють, а тому перевірені варіанти є принципово кращими, ніж ті, які гіпотетично повинні би були працювати.Тем более что цифра в 300 мб явно взята с потолка и не соответствует действительности.
Не треба плутати сарвер АСУ з іншими типами серверів. В нього інші задачі і конструкція як правило теж.
DCB структура оголошена, якщо не помиляюся, у stddef.h Ви можете використовувати цей хідер у Делфі?
Шановний! До чого тут calling conventions?
DCB — взагалі не функція. Це структура.
А оголошення функцій з різними calling conventions на Делфі робиться без ніяких пролем, аналогічно як і на С.
Весь WinApI так підключається.
В чому проблема?
Це було пояснення про
каждое обращение к ним из Паскаля требует дополнительных телодвижений
Тобто STL-ні структури даних працюють з такою ж швидкістю, як нативні?
Що ви розумієте під словом «нативні»? Ви хоч раз мали справу з STL?
структур данных, типа DCB из Паскаля и СШановний! До чого тут calling conventions?
Не зрозумів, яких?
І що значить С-шный синтаксис?
Є просто зміщення конкретного поля в пам’яті.
Є така штука — calling conventions. Серед них є зокрема stdcall та pascal. Вам як любителю асемблерних вставок гріх таке не знати:)
en.wikipedia.org/...ing_conventions
В чому проблема?
З таким підходом до абстракцій у Вас всяка мова буде джерелом багів і проблем. Приклад не зараховується, надто криво написано.
Паскаль зможе це оптимізувати під час компіляції, а STL — ні.Оптимізує компілятор, STL не має до цього ніякого стосунку.
Тобто STL-ні структури даних працюють з такою ж швидкістю, як нативні?
А в Делфі статичний конроль переповнення індексів був вбудований в транслятор ще з першої версії.Звичайно не завжди працює.
Ну да, ну да, только тебе там silverwolf уже привел пример когда статический контроль даже теоретически работать не будет.
До речі — динамічний контроль індексів в Делфі теж набагато кращий ніж в С.
Я мав на увазі, якщо розмір кожного виміру 10, то результуючий офсет буде 367.Взагалі-то треба було зрівнювати більш складні структури, але було вже пізно і я спростив приклад.
Паскаль може це розрахувати під час компіляції, а STL — ні (буде розраховувати в рантаймі).
А робота зі складними структурами без STL буде незручна.
Та і ще питання, наскільки буде зручно працювати з STL порівняно з Паскалівським стандартним синтаксисом.
А что тебя побудило сравнивать plain array и stl вообще?
Стверджувалося, що проблеми можна вирішити за допомогою STL, от я і почав зрівнювати паскалівські нативні структури даних з STL
Тобто ефективність мови програмування визначається ефективністю розробки коду, специфічного для конкретного АСУ, який не можна розробити окремо.
Це називається Domain Specific Language (DSL). Паскаль і Делфі як засоби розробки DSL не катять, на то є Лісп.
Серия очень странных голословных утверждений
Це схоже на троллінг, правда не дуже прямолінійний. Або автор вузько спеціалізувався в АСУ, і трохи не ту мову в юності обрав. Писати про переваги Паскаля і Делфі в цій області трохи маргінально, не той калібр в цих засобів. Та й на лінух в разі чого не дуже розбіжишся портувати (чи зараз модно мати АСУ під Windows 7?) Якщо це справді українська реальність, то я в печалі©.
STL тут абсолютно нічим не допоможеХз, що тут допоможе. Дивні у Вас вимоги до функціоналу ліби.
А як у Вас з тестами? Чи ви прямо на конвеєрі баги лапаєте?
Я в АСУ ні разу не зустрічався з потребою в такому класі, але думаю, що готові реалізації для Делфі існують.
Ну значит у тебя были очень плоские алгоритмы, но не нужно свой опыт экстраполировать на всю отрасль!
2.Цей приклад взагалі не в тему.Помоему это уже начался неадекватный бред. Откуда взялась идея разрабатывать код в риал тайме? Где это у вас так процесс построен?
Бібліотеку збалансованого дерева розробляти в ріалтаймі взагалі не треба.
Її можна спокійно розробити окремо і тільки підключити в робочий проект.
Критично важливими є помилки, які треба відлагоджувати в реальній роботі з апаратурою.
Одна така помилка може важити більше ніж 1000 звичайних, які можна спокійно виправити працюючи по своєму розкладу на окремому компі з відладчиком.
Тобто ефективність мови програмування визначається ефективністю розробки коду, специфічного для конкретного АСУ, який не можна розробити окремо.STL тут абсолютно нічим не допоможе.
“Тобто ефективність мови програмування визначається ефективністю розробки коду, специфічного для конкретного АСУ, який не можна розробити окремо.” — это вообще метафизика какая то...
Думаю, що розробники однакового рівня будуть робити бульше помилок на С++ ніж на Делфі.1. Я в АСУ ні разу не зустрічався з потребою в такому класі, але думаю, що готові реалізації для Делфі існують.
Та ну? Интересно сколько ошибок ты сделаешь в попытке реализвать сбалансированное дерево для класса:
Я на С++ ни одной, потому что оно уже реализовано!
STL тут абсолютно нічим не допоможе.
Я мав на увазі реальні особисті знання.
Я как бы был одним из ее разработчиков, куда уж реальнее?...
Зрозуміло, що є понтові закордоні системи, які декларують багато інсталяцій десь там.
Але практика показує, що на це великої уваги звертати не треба.При практичній перевірці на реальному нашому заводі вони можуть виявитися дуже неефективними.
Серия очень странных голословных утверждений.
Як рішення проблеми пропонувався STL.Той приклад з масивами взятий зі стелі. Чи Ви генерований код читали?
Але STL по функціональності не може повторити нативні типи.
Я показав один конкретний приклад.
Я не бачу жодної причини казати що 3*100+6*10+7 піде в рантайм. І він таки не піде.
Як рішення проблеми пропонувався STL.
Але STL по функціональності не може повторити нативні типи
По якій функціональності? Чого бракує?
Якщо в когось є ще дані — було б цікаво побачити.Я мав на увазі реальні особисті знання.
Я тебе выше описал архитектуру SAP MES, у которой инсталяционная база — тысячи твоих заводов.
При практичній перевірці на реальному нашому заводі вони можуть виявитися дуже неефективними.
Не думаю.
Я знаю багато прикладів обробки апаратури, написаних на Делфі.
В мене нема теоретичного доведення, що на Фокспро це неможливо.
Але це не є підставою писати АСУ на Фокспро.Набагато логічніше йти перевіреним шляхом.
Мы ведь разговаривали про быстродействие и С#, а не проFoxPro и “обробку апаратури”?
Теоретично, якщо я відкриваю локальний pdf-файл, то мій комп’ютер не бав би конектитись в майкрософт.Ты не уловил суть моего аргумента, на современных серверах 300 мб — это 1% памяти, то есть они влияют на свопинг приблизительно так же как и 1 мб.
Але практично ситуація інколи буває інша.
Аналогічно, якщо в мене 1Г пам’яті і програма займає 300 МБ, то теоретично свопінга не повинно бути ніколи.
Але практика показує інше.Тому всі складні фреймворки — то потенціальне джерело проблем, навіть якщо пам’яті ніби і повинно бути досить.
Тем более что цифра в 300 мб явно взята с потолка и не соответствует действительности.
Взагалі — те, що на C# можна написати код, співмірний по ефективності з Делфі, це ще як мінімум треба доводити.Не думаю.Обратное тоже нужно доказывать
Набагато логічніше йти перевіреним шляхом.
Мова йшла про те, що паскалівські структури даних зручніші і швидші в розробці.
Як рішення проблеми пропонувався STL.
Але STL по функціональності не може повторити нативні типи.Я показав один конкретний приклад.
А чем конкретно с-шный масив хуже в удобстве паскалевского в приведенном примере?
А якщо загружена якась джава/C#, то ситуація радикально інша.Теоретично це могло би бути так. Але практично алгоритми роботи вінди дуже дивні.
Если у тебя современный сервер с памятью на пару десятков гиг, и система призвана обрабатывать соответствующие обьемы данных, то размер.net фреймворка не соизмерим с этими обьемами, и решающей роли не играет.
Тому всі складні фреймворки — то потенціальне джерело проблем, навіть якщо пам’яті ніби і повинно бути досить.
1. оптимізований під час компіляції (тобто транслюється в щось типу a [367])Ви згубили зміст розмови.
STL буде обчислювати вираз 3*100+6*10+7 в рантаймі, що буде повільнішеЦе залежить від компілятора. Такі наївні приклади оптимізуються всіма промисловими С++ компіляторами року десь так з 1998.
Мова йшла не про нативні структури даних, які звичайно оптимізуються в С (і напевно навіть краще ніж в Паскалі)
Мова йшла про те, що паскалівські структури даних зручніші і швидші в розробці.STL тут взагалі ні до чого.
Я показав один конкретний приклад.
Не зрозумів, яких?Є така штука — calling conventions. Серед них є зокрема stdcall та pascal. Вам як любителю асемблерних вставок гріх таке не знати:)
І що значить С-шный синтаксис?
Є просто зміщення конкретного поля в пам’яті.
1. А не пытался ли уважаемый Andrew сравнивать вызовы API и заполнение системных структур данных, типа DCB из Паскаля и С?
Давно вже не працював з DCB, але наскільки пам’ятаю, ніяких проблем не було.
Просто там кагбэ С-шный синтаксис и каждое обращение к ним из Паскаля требует дополнительных телодвижений.Не зрозумів, яких?
Є просто зміщення конкретного поля в пам’яті.
2. А не слыхал ли уважаемый Andrew, что пихать аппаратурозависимый код в ГУИ и бизнес-логику суть дурной тон?1.Я про розробку АСУ знаю не зі слухів. Необгрунтовані твердження для мене не авторитет.
Але в моїі практиці їх була абсолютна меншість.
Ця абстракція звичайно має свою область застосування.И что специально изобретена концепция драйвера, для обращения к любому физическому устройству через такую абстракцию, как файловый дескриптор?
Абсолютна більшість АСУ мають інші параметри розробки і екплуатації.
Паскаль зможе це оптимізувати під час компіляції, а STL — ні.
Оптимізує компілятор, STL не має до цього ніякого стосунку. Її код доводили до пуття не першокласники, а якщо у Вас щось і впреться в обчислення індекса, то це не страшно. Зате для С++ є Intel C++ Compiler, а для Делфі яка таргет архітектура остання зараз?
А в Делфі статичний конроль переповнення індексів був вбудований в транслятор ще з першої версії.
Ну да, ну да, только тебе там silverwolf уже привел пример когда статический контроль даже теоретически работать не будет.
Я мав на увазі, якщо розмір кожного виміру 10, то результуючий офсет буде 367.
Паскаль може це розрахувати під час компіляції, а STL — ні (буде розраховувати в рантаймі).
А робота зі складними структурами без STL буде незручна.Та і ще питання, наскільки буде зручно працювати з STL порівняно з Паскалівським стандартним синтаксисом.
А что тебя побудило сравнивать plain array и stl вообще?
вираз a [3, 6, 7] може бутиЯ в своєму прикладі навів не змінні, а константи (a [3, 6, 7])
1. оптимізований під час компіляції (тобто транслюється в щось типу a [367])
STL буде обчислювати вираз 3*100+6*10+7 в рантаймі, що буде повільнішето есть паскаль таки умеет угадывать значение переменных времени выполнения?
Паскаль зможе це оптимізувати під час компіляції, а STL — ні.
2. якщо якийсь індекс виходить за границі, це буде знайдено під час компіляції, а не під час падіння програмиНе пробував — я не дотнеті не пишу.
STL такого не зможе
вы пробывали пользоваться системами code quality?msdn.microsoft.com/...ibrary/bb429476 (VS.80).aspx
А в Делфі статичний конроль переповнення індексів був вбудований в транслятор ще з першої версії.
Простий прикладЯ мав на увазі, якщо розмір кожного виміру 10, то результуючий офсет буде 367.
є тримірний масив a []
вираз a [3, 6, 7] може бути
1. оптимізований під час компіляції (тобто транслюється в щось типу a [367])
STL буде обчислювати вираз 3*100+6*10+7 в рантаймі, що буде повільніше
не понял, что будет медленее и зачем превращать его в число в 10ти значной системе?
Та і ще питання, наскільки буде зручно працювати з STL порівняно з Паскалівським стандартним синтаксисом.
Думаю, що розробники однакового рівня будуть робити бульше помилок на С++ ніж на Делфі.Та ну? Интересно сколько ошибок ты сделаешь в попытке реализвать сбалансированное дерево для класса:
Я на С++ ни одной, потому что оно уже реализовано!
Якщо в когось є ще дані — було б цікаво побачити.
Я тебе выше описал архитектуру SAP MES, у которой инсталяционная база — тысячи твоих заводов.
Взагалі — те, що на C# можна написати код, співмірний по ефективності з Делфі, це ще як мінімум треба доводити.
Обратное тоже нужно доказывать
2. Синтаксис С++ провокує більше помилок.Не згідний.
А тут простите? Это вопрос не языка, а профессионализма разработчика.
Думаю, що розробники однакового рівня будуть робити бульше помилок на С++ ніж на Делфі.
3. Більшість людей в нас писали роботу з апаратурою на Делфі. Є більше інфи, прикладів, бібліотек, форумів.Моя особиста статистика така.Больше чем на C/C++? Не верю!© Кстати, одним «в нас» мир не ограничивается, есть еще «у них»:).
Якщо в когось є ще дані — було б цікаво побачити.
А якщо загружена якась джава/C#, то ситуація радикально інша.
Если у тебя современный сервер с памятью на пару десятков гиг, и система призвана обрабатывать соответствующие обьемы данных, то размер.net фреймворка не соизмерим с этими обьемами, и решающей роли не играет.
Я не знаю зачем ты тут пишешь все эти очень спорные аргументы (про риалтаймовость винды, про быстродействие масивов в делфи, про самые удобные структуры данных в делфи), но как минимум со мной консенсус не достигнут, твоя аргументация выглядит крайне слабой.
Про фреймворки для C# я взагалі мовчу. Є напевно такі сервери АСУ, які запущені в роботу, коли ще і тих фреймворків не було.Пропустив:)
вы наверное пропустили понятие билда в оптимальный код в момент деплоймента?
Може і є якісь хаки, які дозволять по ефективності і функціональності наблизитись до Делфі, але для чого це, якщо можна писати на Делфі і не шукати собі проблем?
насчетЦе важливо тому, що важливою проблемою є свопінг.
АСУ — це реальний час.
Я мав на увазі, що делфійна програма в 1М запускається наприклад за 0.03 сек.разве это время соизмеримо с затратами первичного опроса всех устройств и установки соендинений? к чему это вам так важно?
А якщо загружена якась джава/C#, то ситуація радикально інша.
Проблема в тому, що це треба реалізовувати.Ще раз — питання не в принциповій можливості, а в ефективності.
Помилка в реалізації може коштувати дорого.
А на Делфі ця проблема не існує — я можу написати все в одній програмі, і синхронізувати різні програми просто не потрібно.проблема реализовать правильно библиотеку?
Якщо замість одної програми мені треба писати дві і відладити їхню взаємну роботу реальному часі — це сильно знижує ефективність розробки.
, а Делфі я можу оголосити, що певна адреса в моїй програмі — це те місце, де я хочу отримувати цей виклик таймера.Наскільки я пам’ятаю, коли я працював з таймерами, то для задач вище 10 Гц треба було забути про WM_*
На цій адресі я можу зробити функцію в маш. коді, яку буде викликати система.
Якщо буде треба підняти швидкодію, я можу цю функцію написати повністю або частинно на асемблері.
Для цього мені не треба навіть переключатися в якесь інше вікно, а не те що писати окрему програму на С++.
это не фича Delphi, а операционой системы, и поэтому любая программа это может
msdn.microsoft.com/...ibrary/ms681985 (VS.85).aspx
или вы знаете как вызвать Win API из C#?
или вы думаете C# не имеет доступа к WinAPI или WM_*?
Питання в тому, що ефективніше в розробці і експлуатації.
Постараюсь коротко відповсти сьогодні
Вам привели кучу вариантов... например я не уверен что на Boeing АСУ-ТП реализовано на Delphi;)Звичайно можна, і для деяких випадків напевно і краще.значит можно и без него и в более критических и высокоточных условиях пользоваться не Delphi
І це не тільки мій досвід.
Ні, я такого ніде не казав.2. То есть вы хотите сказать что отображение хеш-таблиц, списков, структур в дебагере Delphi лучше чем в Visual Studio?
Просто хеші в АСУ якось не дуже застосовуються. Тому ця перевага практично нічого не дає в даному класі задач
Я завжди знав, що в деяких компіляторах С++ є хаки, котрі дозволяють наблизитися до Делфі:)3. Кто вам мешает тоже самое сделать в Visual Studio? msdn.microsoft.com/...y/4ks26t93.aspx
Делфі в цьому має суттєву перевагу перед С++, за винятком Visual Studio і, в деякі мірі, gcc.
Я вже відповів десь на це питання.4. Кто мешает подключить готовую библиотеку в C# проект в студии?
Крім того, всі рішення котрі передбачають декілька мов і виконання задачі одночасно декількома програмами, є менш надійними і ефективними, ніж монолітні.
1. оптимізований під час компіляції (тобто транслюється в щось типу a [367])Це залежить від компілятора. Такі наївні приклади оптимізуються всіма промисловими С++ компіляторами року десь так з 1998. STL тут взагалі ні до чого. Хочете подивитись на сучасні техніки оптимізації, почитайте Алана+Кеннеді. Delphi 7 вже відстав, і не дожене.
STL буде обчислювати вираз 3*100+6*10+7 в рантаймі, що буде повільніше
А ще, компілятор краще брати опенсорсний, типу gcc — там при нагоді можна і багу якусь пофіксити, якщо вилізе, а не чекати, поки патч пришлють на 7 Гіг (патч більший, ніж сама система) для 2008 студії. Ну і коммьюніті вас не забуде:)
И что специально изобретена концепция драйвера, для обращения к любому физическому устройству через такую абстракцию, как файловый дескриптор?
Скорее всего имеется ввиду, что паскаль развернет многомерный массив в одномерный.
не похоже, иначе как это понять?
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. якщо якийсь індекс виходить за границі, це буде знайдено під час компіляції, а не під час падіння програмивы пробывали пользоваться системами code quality?STL такого не зможе
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 такого не зможе
1. Кращі структури даних (все що складніше від одномірного масива і вказівника)
Че? Слова STL, Boost,.Net, JCF, Apache Commons, Colt — вам что-то говорят? У любого современного языка есть куча либ со структурами данных.
2. Синтаксис С++ провокує більше помилок.
А тут простите? Это вопрос не языка, а профессионализма разработчика.
3. Більшість людей в нас писали роботу з апаратурою на Делфі. Є більше інфи, прикладів, бібліотек, форумів.
Больше чем на C/C++? Не верю! © Кстати, одним “в нас” мир не ограничивается, есть еще “у них”:).
Не думаю, що в Джаві скоро з’явиться бібліотека для роботи з останніми:)Ні, СОМ порт (як фізичний пристрій) реалізується через декілька апаратних портів вводу виводу.СОМ порт — это не апаратный порт ввода вывода?
СОМ порт як логічний пристрій може бути і не зв’язаний з апаратними портами вводу-виводу взагалі (віртуальний СОМ порт)
Я просто заперечував проти того що Java/C# більш ефективні для даної конкретної задачі.В данной ветке обсуждения ни о какой конкретной задаче речь не шла.
Я в основному говорив про задачі АСУ
Звучит как — я проверил на примере теорему большую Ферма — значит она правильная.
Напевно продуктивна аналогія, але не буду розвивати — пізно вже:)
Будь-яке АСУ — це реальний час. Тому що процес, яким вона керує, відбувається в реальному часі.В двох словах — є системи, де відклик має зміст відносно незалежно від часу.
Это тоже в мемы! Я незнаю ни одной программы которая выполнялась бы в нереальном (фантастическом?)времени.
Якщо система розрахує параметри відкриття заслонки пізніше, ніж через 2 сек., то вже відбулася аварія, і ці параметри вже змісту не мають. Вони вже не відображають реальний стан системи і не несуть ніякої користі.
К тому же, для АСУТП, существуют хорошие С++ фреймворки, например этот или этот.
1. Кращі структури даних (все що складніше від одномірного масива і вказівника)Рекомендую не много почитать про STL, Boost... наверное сила структур с шаблонами и shared_ptr & auto_ptr откроет вам новый мир;)
2. Синтаксис С++ провокує більше помилок. Помилки в системах реального часу коштують дорого.3. Більшість людей в нас писали роботу з апаратурою на Делфі. Є більше інфи, прикладів, бібліотек, форумів.
“может быть вы просто не умете их готовить” — из анекдота;)
1. Кращі структури даних (все що складніше від одномірного масива і вказівника)Delphi — опишите ту нишу в которой он актуален. Если вы все-таки настаиваете на АСУТП — опишите преимущества перед C++.
3. Більшість людей в нас писали роботу з апаратурою на Делфі. Є більше інфи, прикладів, бібліотек, форумів.
1. АСУТПМоя суб’єктивна думка — розробка на Делфі швидша ніж на С++.
C++ + QT?
Крім того синтаксис асемблера зручніший.
2. Деякі задачі із складною логікою і/або не дуже простими структурами даних.Джава повільна.C++/Java/C#/будь-яка інша мова високого рівня?
І взагалі синтаксис С++ провокує більше помилок.
3. Задачі, де треба невелику частину коду замінити на асемблер (на Делфі зручний синтаксис для того, щоб писати на асемблері прямо в коді)Я думаю, що це хороша практика.
Я не спецеаліст у системному програмуванні, але наскільки мені відомо — це погана практика. C/C++?
Крім того інколи важливо саме вставити асемблер в код, а не викликати якусь процедуру на асемблері.
4. Задачі де є готові бібіотеки/програми (наприклад керування певним девайсом)Я не проводив аналіз ринку.
C++/Java/C#/будь-яка інша мова високого рівня?
Бібліотека для Джави (для роботи з девайсом) буде написана на С, тобто на Джаві я її дописувати не зможу взагалі.
P.S. Когда я просил список, то просил список конкретных задач, а не абстрактных. Из всего что вы перечислили только п1 — более-менее конкретный
Вже ніч, так що кокретизувати вже не буду:)
Здається дехто собі слабо уявляє різницю між СОМ-портами і апаратними портами вводу-виводу:).Не думаю, що в Джаві скоро з’явиться бібліотека для роботи з останніми:)
СОМ порт — это не апаратный порт ввода вывода?
Я просто заперечував проти того що Java/C# більш ефективні для даної конкретної задачі.
В данной ветке обсуждения ни о какой конкретной задаче речь не шла.
Можу, це перевірено:)Треба тільки правильно писати програми і конфігурити сервер:)
Звучит как — я проверил на примере теорему большую Ферма — значит она правильная.
Будь-яке АСУ — це реальний час. Тому що процес, яким вона керує, відбувається в реальному часі.
Это тоже в мемы! Я незнаю ни одной программы которая выполнялась бы в нереальном (фантастическом?) времени. Я тебе выше написал, что такое риал тайм система, и что винда ею не являеться.
Об’єктивний факт — не знаю ні одного АСУ на Джаві.
Я думаю что это специфика отечественного рынка, где на это в последние 20 лет были сравнительно небольшие бюджеты. Если делать все по взрослому, например если посмотреть на SAP MES, то это решение на джава, где process control написан на С, работает на спец. девайсах, и общаеться с java посредсвтом xml, а джава все складывает в oracle, реализует красивый web based UI, с красивыми графиками, окошками и т.д.
Delphi — опишите ту нишу в которой он актуален. Если вы все-таки настаиваете на АСУТП — опишите преимущества перед C++.
FPK/Lazarus здається мають все що для цього треба.
C++ + QT? Кроме того, Lazarus — это официальный продукт (вроде был какой-то Kylix)? Насколько я знаю нет, значить его можно засунуть туда же куда и Mono.
Наприклад в джаві нема можливості працювати з апаратними портами вводу-виводу.Здається дехто собі слабо уявляє різницю між СОМ-портами і апаратними портами вводу-виводу:).
java.sun.com/...ducts/javacomm
Не думаю, що в Джаві скоро з’явиться бібліотека для роботи з останніми:)
Тому що є інструменти, заточені під конкретні задачі.Нічого.
Нема інструменту, найкращого для всіх задач.
Да, нету, но это не значит что не нужно пытаться.На данный момент я лучше всего разбираюсь в джава, и в первую очередь пытаюсь применить ее для своих задач, что в этом плохого?
Я просто заперечував проти того що Java/C# більш ефективні для даної конкретної задачі.
Я можу на вінді виконувати певний код гарантовано раз в секунду.Можу, це перевірено:)
В чому проблема?Гарантировано — не можешь
Треба тільки правильно писати програми і конфігурити сервер:)
Покажіть мені хоча б один приклад АСУ, яке не є системою реального часу.
Я не могу тебе показать, но любая делфи АСУ — не риалтайм; -)
Будь-яке АСУ — це реальний час. Тому що процес, яким вона керує, відбувається в реальному часі.
Наприклад в джаві нема можливості працювати з апаратними портами вводу-виводу.Я сам не писав під Linux, і *BSD, але здається там теж без проблем.А как Delphi работает с этими портами на Linux, MacOS, *BSD...?
Але звичайно якщо проект юзає іншу функціональність віндовса, то можуть бути певні ускладнення.
Tому що розробка АСУ на Делфі швидша і зручніша ніж на Джаві (причини я вказав вище)Потому что наверное ты работаешь с отечественными АСУ.
Крім того делфійна програма займає набагато менше пам’яті і швидше виконується, що важливо для роботи з апаратурою.Об’єктивний факт — не знаю ні одного АСУ на Джаві.
Кстати, а как АСУ по английски? MES?
тільки ефективність розробки і експлуатації мабуть буде не дуже.Тому що розробка АСУ на Делфі швидша і зручніша ніж на Джаві (причини я вказав вище)почему? байты становяться другими?
Об’єктивний факт — не знаю ні одного АСУ на Джаві.
на Делфі це буде виглядати приблизно так
asm
in ax, 123
add ax, 67
out 87, ax
mov voltage, axend
Срочно в мемы; -)
Для этого есть понятие состояния, хранение которого и идентификация выноситься из библиотеки — я думаю абстракция хендла в Win API вам знакома, так что не вижу инжинерных проблем тутпроблема реализовать правильно библиотеку?
Проблема в тому, що це треба реалізовувати.
Помилка в реалізації може коштувати дорого.
А на Делфі ця проблема не існує — я можу написати все в одній програмі, і синхронізувати різні програми просто не потрібно.
а как кто-то сказал
АСУ — це реальний час.
это даже плюс
1. Делфі може працювати з апаратурою, асемблером, обробляти таймер і т.д., чого банально не можуть інтерпретовані мови.Простий уявний приклад
почему? или вы думаете C# не имеет доступа к WinAPI или WM_*?или делфи имеет какое-то другое ядро которое реализует эту функциальность?
на Делфі це буде виглядати приблизно так
asm
in ax,123
add ax, 67
out 87, ax
mov voltage,ax
end
Хотів би я бачити, як це буде виглядати на C#Про обробку апаратних таймерів на інтерпретованих мовах — цікаво було б порівняти наприклад обробку мультимедійних таймерів на Делфі і C#, правда в мене вже натхнення закінчується:)
а Делфі я можу оголосити, що певна адреса в моїй програмі — це те місце, де я хочу отримувати цей виклик таймера.это не фича Delphi, а операционой системы, и поэтому любая программа это может
На цій адресі я можу зробити функцію в маш. коді, яку буде викликати система.
Якщо буде треба підняти швидкодію, я можу цю функцію написати повністю або частинно на асемблері.Для цього мені не треба навіть переключатися в якесь інше вікно, а не те що писати окрему програму на С++.
или вы знаете как вызвать Win API из C#?
Я мав на увазі, що делфійна програма в 1М запускається наприклад за 0.03 сек.вы наверное пропустили понятие билда в оптимальный код в момент деплоймента?
А джавішна, навіть 1К, запускається наприклад за 1 сек бо вона піднімає ще цілу джаву.Про фреймворки для C# я взагалі мовчу. Є напевно такі сервери АСУ, які запущені в роботу, коли ще і тих фреймворків не було.
насчет
АСУ — це реальний час.
Я мав на увазі, що делфійна програма в 1М запускається наприклад за 0.03 сек.
разве это время соизмеримо с затратами первичного опроса всех устройств и установки соендинений? к чему это вам так важно?
Я можу на вінді виконувати певний код гарантовано раз в секунду.В чому проблема?
Реальний час спокійно реалізується User Mode.почитайте:
І взагалі в чому проблема з User Mode?
так вот DPC особено в XP которую вы привели ввиде примера позволяет, какому-то девайсу зависнуть на неограничено долгое время и положить ваши User mode applications и тогда вы каждую секунду не увидите...
1. АСУТП1. Вам привели кучу вариантов... например я не уверен что на Boeing АСУ-ТП реализовано на Delphi;) значит можно и без него и в более критических и высокоточных условиях пользоваться не Delphi
2. Деякі задачі із складною логікою і/або не дуже простими структурами даних.
3. Задачі, де треба невелику частину коду замінити на асемблер (на Делфі зручний синтаксис для того, щоб писати на асемблері прямо в коді)
4. Задачі де є готові бібіотеки/програми (наприклад керування певним девайсом)
4. Кто мешает подключить готовую библиотеку в C# проект в студии?
Для этого есть понятие состояния, хранение которого и идентификация выноситься из библиотеки — я думаю абстракция хендла в Win API вам знакома, так что не вижу инжинерных проблем тутПроблема в тому, що це треба реалізовувати.
А на Делфі ця проблема не існує — я можу написати все в одній програмі, і синхронізувати різні програми просто не потрібно.
І взагалі — я не дуже собі уявляю, як наприклад ця програма на джаві буде обробляти таймер в 1 КГц.На Делфі я можу оголосити, що певна адреса в моїй програмі — це те місце, де я хочу отримувати цей виклик таймера.
таймер контролируеться ОС — Делфи тут не причем
Для цього мені не треба навіть переключатися в якесь інше вікно, а не те що писати окрему програму на С++.
Наприклад делфійна програма може бути розміром в 1М, а джаву запустити — це зовсім інші масштаби.АСУ — це реальний час.
програма на C# может быть 100 килобайт так как Framework идет с виндой...
Я опускаю питання пам’яті, свопінга і т.д.
1. АСУТП
Ну да, ее можно написать на делфи, если уже есть куча датчиков и контроллеров, на которых какой нибудь линукс или qnx крутиться; -)
1. АСУТП
C++ + QT?
2. Деякі задачі із складною логікою і/або не дуже простими структурами даних.
C++/Java/C#/будь-яка інша мова високого рівня?
3. Задачі, де треба невелику частину коду замінити на асемблер (на Делфі зручний синтаксис для того, щоб писати на асемблері прямо в коді)
Я не спецеаліст у системному програмуванні, але наскільки мені відомо — це погана практика. C/C++?
C++/Java/C#/будь-яка інша мова високого рівня?4. Задачі де є готові бібіотеки/програми (наприклад керування певним девайсом)
P.S. Когда я просил список, то просил список конкретных задач, а не абстрактных. Из всего что вы перечислили только п1 — более-менее конкретный
Наприклад в джаві нема можливості працювати з апаратними портами вводу-виводу.java.sun.com/...ducts/javacomm
К тому же я прочитал твое оригинальное утверждение, как: в Делфи есть уникальные фичи, которых нету ни в каких других языках. Правильно?
Не треба намагатися робити все одним інструментом.
Почему?
Тому що є інструменти, заточені під конкретні задачі.
Нема інструменту, найкращого для всіх задач.
Да, нету, но это не значит что не нужно пытаться. На данный момент я лучше всего разбираюсь в джава, и в первую очередь пытаюсь применить ее для своих задач, что в этом плохого?
Я можу на вінді виконувати певний код гарантовано раз в секунду.
В чому проблема?
Гарантировано — не можешь
Правда, правда:)
Покажіть мені хоча б один приклад АСУ, яке не є системою реального часу.
Я не могу тебе показать, но любая делфи АСУ — не риалтайм; -)
А є такі типи задач, де нічого кращого ніж Делфі нема.Наприклад:Список в студию!
4. Задачі де є готові бібіотеки/програми (наприклад керування певним девайсом)
Наприклад в джаві нема можливості працювати з апаратними портами вводу-виводу.
А как Delphi работает с этими портами на Linux, MacOS, *BSD...?
А в інших мовах нема того, що є на Делфі.
Например?
Наприклад в джаві нема можливості працювати з апаратними портами вводу-виводу.
Не треба намагатися робити все одним інструментом.Тому що є інструменти, заточені під конкретні задачі.
Почему?
Нема інструменту, найкращого для всіх задач.
Я можу на вінді виконувати певний код гарантовано раз в секунду.Холивара быть не может, потому что есть вполне общепринятое условие риалтаймовости системы — это когда программист может создать условия, при которых гарантировано что какой то код выполниться не позже заданого момента времени. Винда — не риал тайм система,
В чому проблема?
Будь-яка система АСУ — це система реального часу.Правда, правда:)
Это не правда.
Покажіть мені хоча б один приклад АСУ, яке не є системою реального часу.
По теме — делфи лучше не учить конечно же.
Я би сказав, краще не обмежуватись ним:)
почему? или вы думаете C# не имеет доступа к WinAPI или WM_*?1. Делфі може працювати з апаратурою, асемблером, обробляти таймер і т.д., чого банально не можуть інтерпретовані мови.
или делфи имеет какое-то другое ядро которое реализует эту функциальность? откройте Dependency Walker и посмотрите — Delphi использует Windows — и значит любая!!! Windows-програма потенциально это тоже может.
2. На Делфі написано напевно не менше половини наших АСУ, відповідно це не треба починати з нуля. Є всякі бібліотеки, форуми і т.д.
ну вот это аргумент, но опять же зависит от того какой уровень вы себе ставите, думаю на ВАЗе тоже есть море “уникальных” технологий которые вы не найдете на Toyota & BMW, но это не означает что они лучше:)
3. Напевно можна написати сервер бази даних на Джаві (не знаю тільки яка буде продуктивність), але сервер АСУ — то інше. В принципі написати напевно можна (разом з С++), тільки ефективність розробки і експлуатації мабуть буде не дуже.
почему? байты становяться другими? вы слашали что код компилиться в родную для процессора платформу — процессора где это выполняеться, а не собираеться как в случае Delphi, кстати как у Delphi 5 с подержкой Amd64? это к теме производительности
Лабораторная работа 1. Знакомство с Делфи.А є такі типи задач, де нічого кращого ніж Делфі нема.
Список в студию!
Лабораторная работа 5. Вызов сторонних длл из Делфи.
Можна взнати з якими?в плане реальности времени Delphi это User Mode application со всеми от сюдого вытекающими...
Під сервер АСУ береться виділена машина, де запускається тільки АСУ.
Реальний час спокійно реалізується User Mode.если вы хотите создать реальную систему реального времени то добро пожаловать в Kernel mode и там уж Delphi точно не живет:)
Правильно написане АСУ на нормально сконфігурованому сервері працює як годинник.
нагруженная база данных — тоже не обязательно риал тайм система,
имелось ввиду контекста Винды;)
Якщо ж ці функції викликаються через якусь
dll-ку, то де гарантія, що вона не викликається одночасно з двох різних програм. Значить треба додатково писати код, який це фіксає. Його ще треба якось відладити і т.д.
Для этого есть понятие состояния, хранение которого и идентификация выноситься из библиотеки — я думаю абстракция хендла в Win API вам знакома, так что не вижу инжинерных проблем тут
Можна взнати чим?
отображение структурных и сложных данных намного лучше (меньше глюков при разворачивании сложных структур) работает чем в Delphi 7 с которой я когда-то работал, врядли 5я лучше 7й.
Та я і не заперечую, що в плані працевлаштування Делфі — не кращий вибір
это был ответ не вплане даже трудоустройста, в ряде случаев делфи может быть выгоднее, это был ответ на ограничение вашего развития как специалиста... (4 мя странами и заводами наследия СССР)
І взагалі — я не дуже собі уявляю, як наприклад ця програма на джаві буде обробляти таймер в 1 КГц.
таймер контролируеться ОС — Делфи тут не причем
Наприклад делфійна програма може бути розміром в 1М, а джаву запустити — це зовсім інші масштаби.
програма на C# может быть 100 килобайт так как Framework идет с виндой...
А є такі типи задач, де нічого кращого ніж Делфі нема.
Список в студию!
2Andrew — имелось ввиду то что Делфи не дает никакого преимущества перед C#/Java в плане реальности времени на винде...высоко нагруженый сервер БД это тоже система реального времени then, и ничего, смогли же сделать на Java;)1. Делфі може працювати з апаратурою, асемблером, обробляти таймер і т.д., чого банально не можуть інтерпретовані мови.
Принаймі я не знаю ні одного АСУ на Джаві.
А якщо вона ще буде складатися з двох частин, з’єднаних саморобним протоколом, який ще треба теж відладити, то пофіксати всі глюки може і не вдатися.протокол взаимодействия библиотек в системе разработан давно и используя Делфи вы используете его тоже:)
Потрібен не протокол зв’язку абстрактних бібліотек, а протокол роботи з конкретними девайсами.
Кожен раз коли ми виділяєм певну функціональність в іншу бібліотеку, це створює додаткові проблеми.кто вам мешает использовать C++ библиотеку для кода который не воозможно написать на Java/C#
Так що треба цю програму запустити з чотирьох раз. І проходити відладчиком не вийде — пристрої на заводі пауз під відладчиком не роблять.
Можна взнати чим?кстати, отдадка для этих продуктов куда приятнее чем для Делфи...
АСУ — це не 2000 форм написаних 30 індійцями, де треба за тиждень пофіксати роботу 10 форм, які і зараз ніхто не знає, як роблять.
особенно Делфи 5 которая замерла в развитии, а эти продукты активно улучшаються и обрастают...
Ці покращення спрямовані на свої типи задач. А є такі типи задач, де нічого кращого ніж Делфі нема.
проблема вы захотите работать на Западе, к примеру автоматизировать линию на заводе Мерседес... каковы ваши шансы там найти работу со знаниями Делфи?
Та я і не заперечую, що в плані працевлаштування Делфі — не кращий вибір
Думаю, що ефективність такого рішення буде набагато нижча, ніж на Делфі.Я маю на увазі, що на Делфі можна просто написати все що треба.
І ще невідомо, чи воно взагалі запрацює.Делфи работает по тому же принципу, или выдумаете оно выностит Ядро ОС и ставит свое?
Тому схоже що Java+CPP програє по всіх параметрах.
оно использет ряд системных библиотек для работы с устройствами, ряд своих библиотек и КОМ для предоставления более быстрого и легкого доступа...Для звичайної десктопної задачі типу база даних/форма це б приблизно так і було.в случае приведеном мной дизайн будет тот же, только обьекты будут другие:)...
Але для АСУ думаю, різниця може виявитися дуже великою.
А в інших мовах нема того, що є на Делфі.
Например?
Не треба намагатися робити все одним інструментом.
Почему?
Є бажання розвести холівар на тему визначення терміну “реальний час”?
Холивара быть не может, потому что есть вполне общепринятое условие риалтаймовости системы — это когда программист может создать условия, при которых гарантировано что какой то код выполниться не позже заданого момента времени. Винда — не риал тайм система, нагруженная база данных — тоже не обязательно риал тайм система, вообще нагрузка с риалтаймовостью слабо связаны. В тоже время на джава можно строить риал тайм системы, хоть это и не основной тренд сегодня: java.sun.com/...time/index.jsp
Это не правда.Будь-яка система АСУ — це система реального часу.
По теме — делфи лучше не учить конечно же.
поэтому by design, Delphi ничего не может такого особеного чего не могут другие User mode platforms и поэтому тут нет разницы C#/Java vs Delphi у Delphi Могут просто быть уже готовые компоненты на какие-то случаи жизни..., но даже это не беда, С# как детище МСа, прекрасно интегрируеться с COM.
2Andrew — имелось ввиду то что Делфи не дает никакого преимущества перед C#/Java в плане реальности времени на винде...высоко нагруженый сервер БД это тоже система реального времени then, и ничего, смогли же сделать на Java;)
Є бажання розвести холівар на тему визначення терміну «реальний час»?Отлично, а с каких пор делфи на винде стало системой реального времени?...
Будь-яка система АСУ — це система реального часу.
Я думаю зараз для веба краще на Делфі не писати.где там ORM, web frameworks и CMS для делфи?
А Делфі треба використовувати там, де це дає кращий результат, ніж інші мови.
+10 к теме реального времени в Винде...
А якщо вона ще буде складатися з двох частин, з’єднаних саморобним протоколом, який ще треба теж відладити, то пофіксати всі глюки може і не вдатися.протокол взаимодействия библиотек в системе разработан давно и используя Делфи вы используете его тоже:) кто вам мешает использовать C++ библиотеку для кода который не воозможно написать на Java/C++
кстати, отдадка для этих продуктов куда приятнее чем для Делфи... особенно Делфи 5 которая замерла в развитии, а эти продукты активно улучшаються и обрастают...
проблема вы захотите работать на Западе, к примеру автоматизировать линию на заводе Мерседес... каковы ваши шансы там найти работу со знаниями Делфи?Не дуже зрозумів, в чому може бути проблема.
а заводы класа Мухосранский Цех по переработки навоза к примеру это опять же органичение в уровне на котром вы конкурируете и находитесь, я не говорю это не даст комфортных условий вам как девелоперу, но это существено снижает ваши скилы...
Думаю, що ефективність такого рішення буде набагато нижча, ніж на Делфі.Делфи работает по тому же принципу, или выдумаете оно выностит Ядро ОС и ставит свое? оно использет ряд системных библиотек для работы с устройствами, ряд своих библиотек и КОМ для предоставления более быстрого и легкого доступа...
І ще невідомо, чи воно взагалі запрацює.
в случае приведеном мной дизайн будет тот же, только обьекты будут другие:)...
АСУ — це система реального часу, яку відладити і так не просто.
Отлично, а с каких пор делфи на винде стало системой реального времени?...
Може в топіку народ і мав на увазі саме це, але в деяких постах стали доводити що Делфі — це неефективна технологія. А це вже зовсім інше твердження.
Делфи — отличная технология для толстых клиентов с Data Access в виде SQL, но так как мир активно движеться в сторону web и т.д., то делфи уже — да — неэфективна. Тем более что низкая полулярность являеться причиной слаборазвитой экосистемы: где там ORM, web frameworks и CMS для делфи? Где средства построения Continuous Integration, где средства мониторинга для высоконагруженных приложений? А все это есть из каробки на например абсолютно безплатных опен сорс стеках на джаве.
вы имеете ввиду АСУ украинских заводов,
українських, російських, білоруських і казахських
А в чому власне проблеми?которые в большинстве случаев ни о поддержке, обновлении и лицензионном соглашении не думают,
Для того щоб запускати делфійну програму, більше нічого не треба.
а вот если вы захотите автоматизировать к примеру завод на Западе (расширить свою область дальше родной Неньки) может получиться что Делфи не катит...
Не дуже зрозумів, в чому може бути проблема.
кстати, насколько я помню АСУТП то там сильные позиции у С/С++, а для них есть куча вариантов написать Гуй в тех же Жава/Шарп и связать с дравером написаном на С/С++Думаю, що ефективність такого рішення буде набагато нижча, ніж на Делфі.
Там наприклад рухається матеріал по транспортеру і якщо заслонка не відкриється вчасно, то буде аварія.
кстати, насколько я помню АСУТП то там сильные позиции у С/С++, а для них есть куча вариантов написать Гуй в тех же Жава/Шарп и связать с дравером написаном на С/С++
1. Знати щось і обмежуватись цим — не одне і те ж.зная что-то низковостребованое вы ограничиваете свое развитие этой областью, если вам это нравиться и удобно это — ок,
Просто такі задачі рідко попадають в офшор, а офшор зараз в нас — головне джерело робочих місць.
можно продолжить...Не згідний.
на асемблере можно написать то что можно написать на Делфи,но не все что можно на АСМе можно написать в Делфи... итд...
Затрати часу будуть неприпустимо великі. Тому це зробити практично неможливо (тобто вкластись в дедлайн і бюджет)
в топик народ имел ввиду мейнстрим и конкурентность на рынке разработчков... и постулат сводился к тому что благодаря поддержке разработчиков Ораклом и МС у последователей тех технологий больше шансов завтра найти проект и работу...
Може в топіку народ і мав на увазі саме це, але в деяких постах стали доводити що Делфі — це неефективна технологія. А це вже зовсім інше твердження.
но если человек хочет добиться чего-то большего то нужно смотреть и на то что востребовано (проблема что лучше быть единственым програистом в мире на Коболе или одним из тысяч на Жаве... у каждого из аспектов есть свои +/-)
в топик народ имел ввиду мейнстрим и конкурентность на рынке разработчков... и постулат сводился к тому что благодаря поддержке разработчиков Ораклом и МС у последователей тех технологий больше шансов завтра найти проект и работу...
“на Жабе и С# те же задачи” інколи не реалізуються ніяк:)Delphi — уже даже не RAD (потому как на Жабе и С# те же задачи реализуются быстрее),
Для багатьох програм, котрі потребують чогось більшого ніж база даних/візуальні форми, я і на даний момент не бачу чогось кращого, ніж Delphi.
А Java i C# — це для дітей, які в програмуванні нічого, крім малювання формочок не бачили:), а все больше архаичное средство ООП для упертых старых перд...в, все еще страдающих ностальгией по TurboPascal-ю
Особливо C# — це для особливо малих дітей, які не бачили, що сталось із програмістами, котрі присвятили свої кращі роки вивченню технологій Майкрософта.:)
Вот такое мое IMHO.
Ну и поддержка старых проектов естественно.
Делаем поиск по Delphi наУгу, делаем:
monster.com
dice.com...и видим реальную картину:)
На Российском
Все остальные уже покинули или покидают тонущий и обреченный Delphi-карабль
В свое время Делфи был одним из лучших средств разработки. И правильно сравнивать не с.NET, а с тем же MFC. Господа, кому пришлось программировать на MFC? Нравилось? В Делфи было много интересных реализаций и идей. Поддержка CORBA. MIDAS. Огромная база сторонних компонентов. Для информации — тот же популярный DevExpress это изначально были Delphi-компоненты.
На Дельфи удобнее программировать. А для Плюсов больше написано различных библиотек, примеров, фрейморков. Посмотрите еще на C#.NET если планируете под платформу Windows писать приложения. Там и скорость раработки и удобство для программиста, большой набор примеров, решений. А так же есть такие вещи которых больше пока нигде нет=:) Windows Azure
Чё тут спорить. Надо подождать... CodeGear пока расхлебывает борландовский пофигизм к Delphi, а вот как расхлебает и двинется дальше — там и видно будет...
ично я не верю, ни в оптимистичные, ни в пессимистичные прогнозы. Нет, Delphi отнюдь не мертв. И, наверняка не умрет в обозримом будущем. Это добротный, развивающийся продукт, имеющий и постоянно расширяющий свою аудиторию. Если нужны доказательства — извольте... Программа, управляющая подсветкой олимпийских колец в Ванкувере, написана на Delphi. Какие еще нужны доказательства того, что этому продукту доверяют во всем мире?
Никто Delphi не хоронит
MS запустила линейку Visual вдохновившись борландовским C++ Builder. Никакого Delphi тогда и в помине не было.
Это не так. Изначально был именно Delphi. C++ Builder повился позже как Delphi-подобный вариант C++ (приблизительно версия 1 билдера соответствовала версии 3 или 4 Delphi). И кстати, если в Delphi и была какая-то элегантность, то билдер был изначально диковат и разумеется прошедши через время он ни капли не изменился в лучшую сторону.
Естественно — при выборе среды разработчик выберет наиболее привычную...хотя неплохо бы знать хотя бы основные плюсы и минусы нескольких сред разработки. А пользователю то чаще всего фиолетово — на чем написана программа и какие удобства\сложности были у программиста.
JAVA (интерпретируемый язык)
Буга-га!!! Ты хоть сам понял что сморозил чушь???
Я сам на Делфи не пишу и разделяю общий настрой, но в теме откликнулось много «зубров»:) и сообщение для них.
Люксофт недавно искал дельфина
Сравни с «люксофт постоянно ищет жабистов и дотнетчиков»
Имхо у делфи минус один и очень жирный: низкие зарплаты и сложности с поиском работы. Какой — бы не был супер — пупер язык, если изучение его не сулит прибыли даже в перспективе заниматься им я не буду.
Чистая правда. Как и то, что нечестная конкуренция со стороны MS вовсе не означает что Delphi хорош:)
В том-то и дело, что работали. Только, когда стал вопрос о нечто большем, чем рисование форм с кнопками, оказалось намного проще изучить нормальный инструмент, чем пытаться решить задачу с помощью Дельфей.
(на счет серьезно не работать — оговорюсь, не один год опыта работы в разнообразнейших «сферах» его использования)
Какой язык програмирования все таки лучший? Тот, который ты хорошо знаеш. Даже на.net можно сделать конфетку. А на хорошем языке...
Я не вижу проблемы. Какая разница что написано на Delphi? Если система работает?
Если система полностью удовлетворяет требованиям к ней и её больше никогда не нужно сопровождать (даже в теории), тогда, действительно, не вижу никакой разницы, на чём именно она написана. Если же систему предстоит написать, тогда включаются показатели цены, скорости и качества разработки и поддержки. Дискуссия ведь не про то.
Якщо ніші поступово займають сильніші гравці, то хоча б в чомусь ці інструменти мають бути кращими (не обов’язково в усьому) інакше я не розумію, що у цьому випадку є силою.
Я не вижу проблемы. Какая разница что написано на Delphi? Если система работает?
Тому загалом згоден, Delphi таки мертвий, бо майбутнього в нього нема, хіба що животіти де-не-де.
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 лет как писаный мной редактор работает с юникодом, а я не знал, что в Делфи юникода нет... Впрочем, если это про интерфейсные элементы, но на текущий момент уже и это неправда.
Видимо, Вам не приходилось в Делфи работать с многопоточностью через их TThread, Вам не нужен юникод, Вам приятно работать с ОЛЕ и вариантами в их реализации в Делфи, а так же, наверно, не приходилось портировать шарповый код с помощью дисп-интерфейсов, т.к. «других вариантов нет» (желание заказчика + нет реализации не на.Net языках)Delphi — изумительный инструмент
считаю бесперспективным
Це все викликає лише посмішку.Получив прототип, два программиста на C# делали это (фактически — повторяли) месяца полтора...
Мені дуже прикро, що автор знайомий лише з двома хорошими спеціалістами, які використовують C# для вирішення проблем своїх клієнтів.
Спорненько, я тут недавно поигрался в Qt, так скажу, что тоже самое, но в разы легковеснее. Правда, что такое класс надо таки понимать, тупым накидыванием компонентов на формочку тут не обойдешься.но если нужно что то по быстрому написать под вин32 — кроме делфи вариантов нет...
А вобще по-настоящему Дельфи вынесут те ребята, которые прикрутят быструю рисовалку формочек к Питону.
че из этого выйдет — покажет время
P.P. S. Единственная толковая программа, которая мне известна на.NET, это Paint.NET.
to eugene_n
Таки да: о) Delphi 3 + AsyncPro — выбор последних 10 лет: о)) Быстро создал тестовое ПО (и таки да — на проверку обмена) и все: о))Никакой иронии. Для инженера которому надо быстренько кинуть и прочитать несколько текстовых строк во внешнее устройство ничего лучше придумать нельзя.
to flymanЗа строгость типов — да, есть такое...
2eugene_n
А что же такого в есть Делфи, чтобы его уважать?Там какая никакая строгость типов, а не такая xyіта, когда на лету делаеш каст, и тебе всё пофиг.
Но ответьте пожалуйста — для решения каких прикладных задач delphi был создан изначально? Win32 desktop, не так ли? — в процессе своего длительного развития, произошли ли какие-либо изменения в этом списке задач? Интересуюсь искренне, Дельфи не видел лет 5 уже, мой опыт с ним сходен с опытом eugene_n — в определенный момент выяснилось, что «слепить формочку» намного быстрее и удобнее на VB, а больше задач для Дельфи как-то и не видно. — вот эта вот «ниша» задач, где Дельфи — идеальный выбор по сравнению со всем остальным, она насколько широка в данный момент?
подразумевает некую степень иронии свашей стороны
Никакой иронии. Для инженера которому надо быстренько кинуть и прочитать несколько текстовых строк во внешнее устройство ничего лучше придумать нельзя.
To eugene_n:
быстро слепить графическое приложение на коленке
подразумевает некую степень иронии свашей стороны поетому не соглашусь с вами в полной мере. Но в некотором смысле ви действительно правы: Delphi позволяет быстро (а для заказчика это слово звучит и как «дешево» ) сделать графическое приложение — например для работи з базами данных. Конечно я не буду отстаивать точку зрения что на Delphi стоит разрабатывать веб приложения или низкоуровневые вещи. Согласитесь, каждый инструмент хорош для решения своих специфических задач. Именно в таком ключе я и рассматриваю Delphi.
Delphi нужен для того, чтобы потом переписывать на NET:). Это же сколько денег надо на переписывание тратится
Не очень много. В основном это связано с тем, что Делфи позволяли быстро рисовать формочку. Когда же дело доходило до многопоточности и сторонних библиотек (в моем случае djvu) Делфи начинал очень круто пробуксовывать. Поэтому я просто уделил некоторое время изучению wxWidgets и gtk и забыл поделие Борланда как страшный сон.А у вас сколько опыта разработки на Delphi?
В настоящее время я позиционирую его как средство быстро слепить графическое приложение на коленке. А вы?
Ну что ж, я как человек которому приходится работать и на.NET и на Delphi могу сказать следующее: вы абсолютно правы. И вам как человеку который имеет опыт разработки и на и на.NET и на Delphi должно быть известно все pro and cons каждой из упомянутых технологий. И вы вероятно не написали бы ничего из ниже перечисленого:
Вона ще довго-довго житиме, бо її у вузах викладають.
Delphi мертвый язык? Да, и уже даже не пахнет.
сейчас это просто маргинальная экзотика
итд...Паскаль подохне остаточно, коли повиздихують викладачі, котрі нічого крім паскаля не знають.
Мои коментарии были для тех кто ето написал ибо они видимо знают о Delphi только по наслышке.
В последствии стали очевидны дополнительные бонусы: — Более широкий выбор технологий, компонент, библиотек (не UI), по сравнению с теми, что доступны для Delphi. — Меньше шансов внедрить критические ошибки в систему у младших разработчиков. (В силу отсутствия указателей и прочих радостей неуправляемого кода.)
Каждая технология/язык программирования etc. создаются не для того чтобы утешить очередного программиста новой фичей, а для решения прикладных задач. Я работал над созданием систем на Delphi которые обслуживали предприятия со штатом в несколько тысяч людей. И если технология позволяет решать такие задачи — то уже только за это ее надо уважать. И если технология позволяет переводить кубические дюймы в... то и за ето ее нужно уважать.
А что же такого в есть Делфи, чтобы его уважать?Delphi не в почете потому что просто так принято — єто как будто правило хорошего тона.
В принципе у Делфи осталась изначальная ниша — среда программирования для непрограммистов. Делфи на ура идет у инженеров, которые пишут на нем всякие калькуляторы для перевода кубических дюймов в квадратные футы и опросы удаленных датчиков через СОМ-порты.
Мне никогда не был понятен этот тандем. Производительности у плюсов не намного больше, функциональности языка тоже.Вариант ГУЙ — на делфи, Функционал на плюсах мы уже не рпссматриваем? ИМХО в прошлом такой тандем был популярен для виндовс-десктоп приложений
А для особо влюбленный в кресты изначально существовал Ц билдер, на котором гуй редактор был точно такойже что и на делфи.
Я сам долгое время работал на Delphi (да и сейчас немножко) и складывается впечатление что Delphi не в почете потому что просто так принято — єто как будто правило хорошего тона. Я это очень часто вижу ещо с института. Да все учили Delphi в институтах, но вот просто интересно, сколько из висказавшихся здесь имеют комерческий опыт работы с этим продуктом/технологией. Множество мнений которие я слышал о Delphi в своей жизни исходили от людей у которых весь опыт работы с Delphi это 5−10 лабораторных работ.
Ни чего не могу сказать про Делфи как фреймворк для разработки, но с точки зрения карьеры, за 6 лет активного мониторинка ИТ рынка Финляндии вилел всего 3−5 вакансий, т.е. меньше чем одно предложение в год. Так что делайте выводы.
Сергей Волошин, а може бейсік? він то взагалі 1963й...
Вариант ГУЙ — на делфи, Функционал на плюсах мы уже не рпссматриваем? ИМХО в прошлом такой тандем был популярен для виндовс-десктоп приложений
В линуксе он мог бы быть написан с помощью Kylix, там как раз и Qt и C++.
Скайп работает не только под Windows. В Линуксе он использует С++ и Qt. Странное решение использовать Delphi для Windows. Видимо вначале была версия для Windows сделанная неподумав, а потом пришлось поддерживать два языка, жуть:)
П.С. І сказала сьогодні наша викладачка (з кафедри програмування доречі) С то продовження Паскаля
PS да, а соответствующих вакансий в последнее время стало больше — похоже в Украину зашли зарубежный проекты на Delphi.
Дельфи же как технология де-юре мертва с момента ее перехода на.Net. И это после относительно безоблачного прошлого, что вдвойне обидно. Сразу вспоминается полуось:) Факты же в том, что разработчики Паруса (ну и PLSQL developer’а) попали в довольно неприятную ситуацию — часики тикают, спецов по Дельфи будет только меньше и гарантий что все нужные в будущем фишки можно будет сделать — никаких, надо или мигрировать куда-то, или с нуля писать, и неизвестно что лучше. Оракл-то, я уверен, выкрутится — пригласят пару лишних раз клиентов на гольф и втюхают таки им свой продукт пятилетней давности, им не привыкать. Бухгалтерия тоже, за счет vendor lock-in, побарахтается еще какое-то время. Но начинать новый проект на Дельфи — самоубийство.
to andy
не понял юмора, ну возможности 1с, ну и что:)) v8.1c.ru/buhv8
На какой точно версии не знаю. Понятно, что дельфи не майнстрим, работу по нему в Украине днем с огнем не найти, но все же он не мертвый, на нем до сих пор, даже за бугром, делают хорошие программы
Сейчас какой то почитатель сей штуки выдаст, что-то типа: «Контр страйк написали у Делфи»...
насколько знаю, так называемый «старый Qip» автор написал на делфи, потом видимо понял, что не, фигня, и переписал «с нуля» на Qt и назвал его Infium (:
Ну, а про стартап The Bat-овців легенди ходять:) В ті часи Делфі ще було конкурентно спроможне.
:)) 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 — сейчас это просто маргинальная экзотика (как и Парус Бухгалтерия:)
Кроме того почти у каждого стоит, что-то из этого популярного ПО:
Ну и что? Список софта написанного на С будет много больше, но это не значит что на Украине куча работы для сишников.
А мова — Паскаль. Вона ще довго-довго житиме, бо її у вузах викладають.
Oleg Lavronov
Roman R.
Valentyn Mykylyuk
Дмитрий Ковтун
Nikolay Ponomarenko
Igor Poloz
454 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів