Форум: "Прочее";
Текущий архив: 2010.08.27;
Скачать: [xml.tar.bz2];
Вниз
Delphi - "рулез форева"! Найти похожие ветки
← →
Германн © (2010-02-14 01:50) [0]Пусть он до сих пор не имеет русской локализации. Пусть он дорогой.
Но я почти уверен, что если бы Борланд (по словам АП) не отказался в своё время от Basic"а, то у нас была бы ещё одна нормальная среда разработки. А не это (пусть и бесплатное, пусть и русифицированное) дерьмо от MS - Microsoft Visual Basic 2008 Express Edition!
Может, конечно у меня руки кривые. Но уже замучался открывать старые проекты. Сыплются в диком количестве ошибки непонятные. На каждую выдается поиск в справке. Поиск их не находит ни на локале, ни в сети. Что делать совершенно непонятно.
Неужели есть только один выход? Создать новый проект и доработать его до конечного продукта за один сеанс.
P.S.
Модераторы, конечно в праве удалить сей пост.
P.S.S
Но некоторым из них стоит задуматься.
← →
Германн © (2010-02-14 02:05) [1]В этой MS-поделке есть "Создать проект". Есть "Открыть проект". Есть "Закрыть проект".
Но нет "Сохранить проект"!
← →
Eraser © (2010-02-14 02:26) [2]да, на удивление, до сих пор Делфи это лучшая RAD для win32, imho.
← →
Германн © (2010-02-14 02:36) [3]
> Eraser © (14.02.10 02:26) [2]
И к тому же "простопонятная" любому новичку.
Наверно именно поэтому они (новички) и лезут в первую очередь на ДМ со своими вопросами. :)
Но мне то надо проверить .Net-библиотеку. :(
← →
Eraser © (2010-02-14 02:38) [4]> Но мне то надо проверить .Net-библиотеку. :(
почему тогда не C#? там все куда более вменяемо, чем VB.
← →
Германн © (2010-02-14 02:45) [5]
> Eraser © (14.02.10 02:38) [4]
>
> > Но мне то надо проверить .Net-библиотеку. :(
>
> почему тогда не C#? там все куда более вменяемо, чем VB.
>
>
Дело в том, что С# не знаю ни я, ни разработчики той библиотеки. У них (разработчиков) все примеры на VB.
← →
Германн © (2010-02-14 03:13) [6]
> Eraser © (14.02.10 02:38) [4]
"This ain"t no technological breakdown
Oh no, this is the road to hell"
(с) Chris Rea
← →
KilkennyCat © (2010-02-14 09:15) [7]"Кому и кобыла - невеста"
← →
@!!ex © (2010-02-14 09:40) [8]> [2] Eraser © (14.02.10 02:26)
QT вполне достойная.
Пока единственное что хуже Дельфи - скорость компиляции.
Дельфи привычку выбаратывает компилировать часто, чтобы проверять мелочи...
а в QT так не получается...
← →
Anatoly Podgoretsky © (2010-02-14 11:18) [9]
> почему тогда не C#? там все куда более вменяемо, чем VB.
А чем VB.NET не вменяемо?
← →
Anatoly Podgoretsky © (2010-02-14 11:19) [10]
> Германн © (14.02.10 01:50)
А если бы Микрософт не отказался от Паскаля, то две среды. А Паскаль от МС уже в те времена мог делать OBJ файлы.
← →
Anatoly Podgoretsky © (2010-02-14 11:19) [11]Pascal.Net Express
← →
@!!ex © (2010-02-14 14:05) [12]> [8] @!!ex © (14.02.10 09:40)
Прочитал книгку про QT4.5
технология весьма мощная, несмотря на то, что она значительно моложе дельфи, некоторые вещи реализованы значительно лучше, например почти полностью автоматическая интернационализация.
← →
BiN © (2010-02-14 15:27) [13]
> Delphi - "рулез форева"!
некоректное сравнение.
Тогда давайте уж возьмем Delphi и MS VS 2010 RC
← →
MBo © (2010-02-14 16:44) [14]По некоторым данным, сегодня Delphi 15 лет - 14 февраля 1995 г вышла первая версия. Опять нет повода не выпить... ;)
(Rob"s Technology Corner – On February 14, 1995 the first version of Delphi was released
The development of Delphi started in 1993 and Delphi 1.0 was officially released in the United States on 14 February 1995)
← →
Eraser © (2010-02-14 17:09) [15]> [12] @!!ex © (14.02.10 14:05)
по моему QT все таки больше под кроссплатформенность заточена, если не ошибаюсь. а для написания приложений, активно взаимодействующих с самыми различными компонентами ОС QT не очень удобен.
← →
Делфиец (2010-02-14 18:43) [16]
> Eraser © (14.02.10 02:38) [4]
> > Но мне то надо проверить .Net-библиотеку. :(почему тогда
> не C#? там все куда более вменяемо, чем VB.
А чем же оно лучше RAD Studio ?
Мы уже этого насмотрелись. Стоит какой серьезный проект на C# нем начать, то годами можно делать, так и вышло в одном месте уже 4 года клепают и клепают, а конца и края не видна. Чуваки взялись проект делать а в итоге вторую "Визуаль студию" написали. А перед этим хвалились и хвалились, "что С# это круто, да там так много компонентов"
Да куда им грешным тягаться супротив стандартных компонентов в RAD? А если к проекту прицепить VCL JEDI - вообще закопаются.
Да так оно и есть, лучше нормально заплатить и купить нормальную и полноценную "RAD Studio" горя не знать, чем маяться как плюшкиным от скудости компонентов и писать заново VS.
← →
GDI+ (2010-02-14 19:20) [17]
> @!!ex © (14.02.10 14:05) [12]
>
> > [8] @!!ex © (14.02.10 09:40)
>
> Прочитал книгку про QT4.5
> технология весьма мощная, несмотря на то, что она значительно
> моложе дельфи, некоторые вещи реализованы значительно лучше,
> например почти полностью автоматическая интернационализация.
И два глобальных недостатка
- программы на QT поддерживают скины и собственные неоконные контролы, что позволяет полностью изменить поведение программы на отличное от системного. Оно же недостаток - вы будете заново привыкать к интерфейсу программы.
- довесок к любой программу в 12 Мб dll или размер екзешника с одной формой в 8МБ при статической линковке.
В остальном рвёт NET и пр, как по переносимости ПО, по скорости его работы, так и по скорости разработки не уступает (в платной версии, в бесплатной нет интеграции дизайнера форм в среду) Delphi и .NET.
← →
@!!ex © (2010-02-14 19:33) [18]> [15] Eraser © (14.02.10 17:09)
Нет никаких проблем написать виджет работающий с ОС.
Там же прямой доступ к ОС функциям. Типа:
painter.paintEngine()->getDC() - и вот уже у нас виндовый HDC обычный.
В целом ощущение, что от дельфи взяли лучшее и некоторые моменты серьезно переработали.
> [17] GDI+ (14.02.10 19:20)
Разве поддержка скинов - это недостаток?
Хочешь используешь, не хочешь - не используешь.
Скорее достоинство, т.к. позволяет сделать единый интерфейс во всех ОС.
Вот скайп работает с собственным стилем, к чему там привыкать?
Это если идиотично подойти к использованию стилей - тогда да, проблем...
но не РАД, а конкретной программы. Тем более что дельфи также легко использует скины, достаточно DynamicSkinForm подключить.
> (в платной версии, в бесплатной нет интеграции дизайнера форм в среду)
QT Creator бесплатный и с интегрированным дизайнером.
но все равно по скорости разработки дельфи не рвет.
Не рвет ИМХО по двум причинам:
1) Медленная компиляция - лишняя прослойка в компиляции(qmake) скорости совсем не добавляет...
2) отсутствие быстрых шаблонов(например автоматического создания событий нету, описание метода в классе не добалвяется в код при нажатии комбинации как в дельфи(Ctrl+Shift+C) или я просто не нашел как это делать).
Но, конечно, компиляция - самая жесть...
← →
miek (2010-02-14 19:54) [19]Кто сказал, что Делфи - доргоая среда? Для BDS можно официально получить бесплатный ключ (что я и сделал). И под ним даже можно делать коммерческие проекты.
Правда, у МС тоже есть VS Express.
← →
Kerk © (2010-02-14 19:56) [20]
> miek (14.02.10 19:54) [19]
> Для BDS можно официально получить бесплатный ключ (что я
> и сделал). И под ним даже можно делать коммерческие проекты.
Народ в лице меня жаждет подробностей!
← →
@!!ex © (2010-02-14 20:00) [21]> [19] miek (14.02.10 19:54)
Проблема дельфи не столько в том, что она дорогая... а в том что она убогая.
IDE просто отличная, но сама концепция устарела и не развивается.
Компилятор только под Win и только 32(это во вреемена, когда уже практически нельзя купить новый 32 битный комп).
VCL нормально работает только в однопоточной среде(это во времена, когда на конвеер уже поставлены 8 ядерные процессора).
Подход к справке не изменился с самой первой версии, хотя давно пора.
Хорошо хоть Unicode сделали...
Подход к VCL весьма не удачный, в пределах одного модуля можно увидеть разные стили программирования и разные реализации одних и тех-же вещей.
Развитие идет по каким-то странным направлениям типа поддержки generics, которые безусловно замечательная штука, но далеко не первая необходимость....
Это все и заставило лично меня заняться поиском альтернатив. :(
← →
@!!ex © (2010-02-14 20:01) [22]> [20] Kerk © (14.02.10 19:56)
>
> Народ в лице меня жаждет подробностей!
Turbo Delphi Explorer?
← →
Kerk © (2010-02-14 20:27) [23]Turbo Delphi Explorer слишком обрезана. Там человек про BDS говорил.
← →
boa_kaa © (2010-02-14 20:39) [24]
> Eraser © (14.02.10 17:09) [15]
> если не ошибаюсь. а для написания приложений, активно взаимодействующих
> с самыми различными компонентами ОС QT не очень удобен.
я таааааак смеялсо...
> @!!ex © (14.02.10 19:33) [18]
> 1) Медленная компиляция - лишняя прослойка в компиляции(qmake)
> скорости совсем не добавляет...
ну так надо как в поговорке: семь раз откодь, один отбилдь
> 2) отсутствие быстрых шаблонов(например автоматического
> создания событий нету, описание метода в классе не добалвяется
> в код при нажатии комбинации как в дельфи(Ctrl+Shift+C)
> или я просто не нашел как это делать)
да ты подожди: где-нибудь к версии 2 будет еще и полноценный эмулятор нокий в бесплатной версии :)
← →
KilkennyCat © (2010-02-14 20:43) [25]
> ну так надо как в поговорке: семь раз откодь, один отбилдь
а посредине, один хрен, гвоздик...
← →
@!!ex © (2010-02-14 20:53) [26]> [23] Kerk © (14.02.10 20:27)
В нем вроде обрезана только установка пакетов, это решается патчем(в рамках лицензии).
> [24] boa_kaa © (14.02.10 20:39)
> ну так надо как в поговорке: семь раз откодь, один отбилдь
Большее количество компиляций - большее количество тестов - больше стабильность готового кода.
Мне этим очень нравится дельфи, что можно проверить почти каждую написанную строчку кода по отдельности. С++ как раз учит, что надо долго писать, а потом один раз компилировать и все проверять...
Дельфи подход ИМХО более правильный и предотвращающий дурацкие ошибки.
Ожидаю ответа в духе: "писать надо без ошибок." ;)
← →
KilkennyCat © (2010-02-14 21:05) [27]
> Ожидаю ответа в духе: "писать надо без ошибок." ;)
именно. Ибо большее количество компиляций происходит при включенном оптимизаторе и на одной машине, что не гарантирует ни одинакового результата, ни повторяемости на другом компе.
← →
GDI+ (2010-02-14 21:11) [28]
> @!!ex © (14.02.10 20:53) [26]
>
> > [23] Kerk © (14.02.10 20:27)
>
> В нем вроде обрезана только установка пакетов, это решается
> патчем(в рамках лицензии).
>
>
> > [24] boa_kaa © (14.02.10 20:39)
> > ну так надо как в поговорке: семь раз откодь, один отбилдь
>
> Большее количество компиляций - большее количество тестов
> - больше стабильность готового кода.
Юнит-тесты? Просто идеология C++ в том чтобы на каждый метод и функцию писалась функция для тестирования которая в специальный лог запишет прошло тест или нет.
Но на это обычно забивают, а потом разгребают.
Ну и юнит-тесты частые компиляции не панацея, так как разработчики других продуктов часто воспринимают документацию не как аргумент, а как "забавное" чтиво. Особенно глюкавы всяческие антивирусы и фаерволы.
← →
Kerk © (2010-02-14 21:16) [29]
> @!!ex © (14.02.10 20:53) [26]
>
> > [23] Kerk © (14.02.10 20:27)
>
> В нем вроде обрезана только установка пакетов, это решается
> патчем(в рамках лицензии).
Врядли в рамках лицензии, иначе какой смысл в этом ограничении изначально. Но буду рад, если меня разубедят ссылкой :)
Там еще, кстати, нормальных компонентов для работы с БД нет, что вкупе с запретом установки пакетов полностью лишает Turbo Delphi смысла.
← →
Dimka Maslov © (2010-02-14 21:21) [30]Разработчики Delphi не обещали в 1995, что через 20 лет все будут жить при коммунизме.
← →
@!!ex © (2010-02-14 21:22) [31]> [27] KilkennyCat © (14.02.10 21:05)
Я вроде о программировании драйверов ничего не говорил...
В процессе разработки включать оптимизатор зачем?
Как раз подход "несколько строчек - проверка" позволяет проверить работу конкретного блока кода, когда поведение вполне однозначно и проверить легко.
Опять же, мы же говорим о тестировании RAD, обычно блоки тестить в плане визуально работы довольно легко.
> [28] GDI+ (14.02.10 21:11)
Я пока не понял как писать юнит тесты для графики, идеи есть, но что-то пока не очень удачные.
и в целом, по моим впечатлениям юнит тесты нужны не во время разработки, а во время рефакторинга, чтобы не сломать то, что уже работает.
Вообще я с некоторой гордостью смотрю вот на этот проект:
http://www.youtube.com/watch?v=lQuG9ZWBGrs
Гордость за то, что он не вызывает AV. Никогда. И при этом try except end заглушек нет нигде.
За год работы нескольких десятков дизайнеров данные были потеряны один раз: во время джлительного сохранения дизайнер кликнул на крестик у окна, а для ускорения сохранения ProcessMessages не вызывается, в итоге система грохнула редатор как зависший.
← →
@!!ex © (2010-02-14 21:24) [32]> [29] Kerk © (14.02.10 21:16)
http://arcady-filippov.blogspot.com/2006/09/td.html
http://arcady-filippov.blogspot.com/2006/12/turbo-delphi-2.html
← →
Игорь Шевченко © (2010-02-14 21:25) [33]Kerk © (14.02.10 21:16) [29]
Можешь использовать Lazarus и FPC.
> Там еще, кстати, нормальных компонентов для работы с БД
> нет, что вкупе с запретом установки пакетов полностью лишает
> Turbo Delphi смысла.
Зато даром. А если не хочешь приложить усилия - ну кто же за тебя их будет прикладывать, платы денег за, как минимум, Turbo Delphi Professional, не так дорого.
← →
KilkennyCat © (2010-02-14 21:31) [34]
> @!!ex © (14.02.10 21:22) [31]
> Я вроде о программировании драйверов ничего не говорил..
Да и я не о них. Было, что моя прога изумительно работала на моей машине. Нифига не работала у клиента. Вся разница - у мня амд, у него - интел. Никакой переделки, простая компиляция на интеле - работает и там и там. Ни тогда, ни сейчас я не имею знаний и умения программировать с учетом специфики процессора, т.е. ничего заумного не применял.
← →
oxffff © (2010-02-14 21:37) [35]Скоро появится новый framework. За ним другой, за ним третий.
← →
@!!ex © (2010-02-14 21:40) [36]> [34] KilkennyCat © (14.02.10 21:31)
Не сталкивался с таким пока. тьфу-тьфу-тьфу.
> [35] oxffff © (14.02.10 21:37)
Нормальное развитие.
← →
Loginov Dmitry © (2010-02-14 21:48) [37]
> VCL нормально работает только в однопоточной среде
>
Недавно испытывал многопоточность "VCL" в Sharp Developere (скачивал последний релиз).
Выдается вполне цивильное сообщение об ошибке, объясняющее, что к визуальному объекту нельзя обращаться из других потоков.
Жаль, что такого нету в Delphi.
← →
Делфиец (2010-02-14 22:03) [38]
> @!!ex © (14.02.10 20:00) [21]
А
> это во времена, когда на конвеер уже поставлены 8 ядерные
> процессора)
А что уже на конвеер поставлены 64 разрядные Windows?
Пока там у мелкомягких еще пока "сырое мясо".. Все равно у всех 32разрядные системы и не скоро перейдут на 64 битные.
Так что МЫ НЕ ТОРОПИМСЯ! +1 в сторону BDS
← →
Демо © (2010-02-14 22:42) [39]
> А что уже на конвеер поставлены 64 разрядные Windows?
> Пока там у мелкомягких еще пока "сырое мясо"..
А что - нет?
Прекрасно работаю x64-версии. Не надо ля-ля.
← →
Делфиец (2010-02-14 22:43) [40]Большим недостатком .NET - жрет память гадина постоянно.
Когда начинали проект, закупили по тем временам компьютера (2.4 гц. целероны 256мб. оперативки) средней мощности, но года установили армы написанные на С# + Фреймворк 2.0 MS SQL Expres на каждый, то поняли что памяти мало только фреймворк при загрузке 40-70мб отъедает памяти, тогда пришлось на всех компьютерах увеличить память до 512мб. Через некоторое время опять возникли проблемы (через 1.5 года работы АРМов) Базы разбухли и достигли предела, который ограничивался 4гб. согласно лицензии от MS на Expres версию. Ситуация была трудной - никто не знал что произойдет, когда базы достигнут более 4гб. А производство остановить нельзя, т.е. невозможно (великий глюк наступит) приходилось их чистить постоянно, удаляли лишние события и служебные записи и логи во вред безопасности. Теперь ситуация более менее, но уже снова приходится увеличивать память на компьютерах до 1гб., но уже возникла другая ситуация компьютеры уже устарели и память DDR1 днем с огнем не сыскать, а там где она есть в той фирме конторе покупать нельзя, а значит по сути ее нет.
Ну асли бы использовали Субд с использованием NET 3.5 версии, вообще бы "слили воду бы" .
← →
@!!ex © (2010-02-14 22:49) [41]> [40] Делфиец (14.02.10 22:43)
ИМХО .NET - бред безумца... Редкостная гадость.
ИМХО ИМХО ИМХО ИМХО ИМХО
← →
boa_kaa © (2010-02-14 22:49) [42]
> Делфиец (14.02.10 22:43) [40]
а посмотреть системные требования на MS SQL, конечно, никто не догадался...
← →
boa_kaa © (2010-02-14 22:52) [43]
> @!!ex © (14.02.10 22:49) [41]
> ИМХО .NET - бред безумца... Редкостная гадость.
> ИМХО ИМХО ИМХО ИМХО ИМХО
а чем? а чем? а чем? а чем? а чем?
← →
Вовчик (2010-02-14 22:57) [44]2 @!!ex
Не устанавливаются компоненты в dclusr.dpk. То ли я чего не так делаю, то ли в скачанном дистрибутиве от 21 июня 2007 года этот "баг" пофиксили. Если второе, то как бы поиметь более старую версию дистрибутива Turbo Delphi, которая все еще поддерживает установку пользовательских компонентов?
← →
Делфиец (2010-02-14 23:01) [45]
> Демо © (14.02.10 22:42) [39]
Что ля - ля то..
Что то еще не у кого не видал на производстве. только в нашей конторе свыше 2000 компьютеров и ни как не видел, что хоть кто-нибудь в дирекции информационных технологий заморачивался по 64 разрядным системам, кроме как на серверах. Это дома для своих целей хоть, что устанавливайте, единичные случаи не в счет.
1. лицензии на 64 разрядные ОС дороже, а значит и покупать "большими пачками" ни кто не будет.
2. возможно есть некие проблемы в совместимостью с уже написанными и работающими 32бит. АРМ`ами 1С, Ораклом и уже всем поглощающим САП`ом, мы не тестировали, да и вы не тестировали, их переписывать никто не будет под 64бит а значит так и останутся 32бит. Тогда вопрос, а зачем нам в таком случае 64битные ОС, если на них все равно будет 32 битное ПО и АРМы крутиться будут?
← →
Делфиец (2010-02-14 23:14) [46]
> boa_kaa © (14.02.10 22:49) [42]
> > Делфиец (14.02.10 22:43) [40]а посмотреть системные
> требования на MS SQL, конечно, никто не догадался...
Никто не говори то про идеальность руководителей, которым вообще было до лампочки, когда подписывали проекты, то как они просто л..хи.
Так получилось, что сперва одна фирма начинала проект поделали поделали или только вид создали, что делают деньги выманили "сорвали куш", а затем наняли другую для доводки и доделки т.е. для внедрения, а там на 50% было только сделано - типичный лохотрон. А вот та фирмачка, которой все досталось доделывать все самое трудно и ляпы оказалась довольно честной и добросовестно доводит проект до финала молодцы много сделали. А с той фирмой, с которой начинали всего уже не будут никаких договоров заключать.
← →
Дмитрий Белькевич (2010-02-14 23:42) [47]Замена эврикалога для QT есть? Кстати, для нативных плюсов тоже интересны аналоги.
← →
Игорь Шевченко © (2010-02-14 23:48) [48]Делфиец (14.02.10 23:01) [45]
> Тогда вопрос, а зачем нам в таком случае 64битные ОС, если
> на них все равно будет 32 битное ПО и АРМы крутиться будут?
>
Даже для 32-х битных приложений под 64-битными системами физической памяти памяти больше видно.
В 64-х битных системах проблем нет ни с ораклами, ни с виндами, ни с .Net-ом. Проверено электроникой.
← →
Плохиш © (2010-02-15 00:01) [49]
> Делфиец (14.02.10 23:14) [46]
А мелкий софт по-привычке виноват?
← →
Германн © (2010-02-15 02:24) [50]Справился с этой "поделкой/(подделкой под нормальный продукт)".
Оказывается он очень критичен к файловой структуре проекта. Вот уж блин не ожидал такого! В него можно добавить любой "модуль в его понимании" из любого места в файловой системе компа и он не ругается. Но последствия - не предсказуемы. Либо проект будет не читаем при следующем открытии, либо он не сможет быть откомпилирован, либо...
← →
Германн © (2010-02-15 02:28) [51]При этом нашел ещё и дополнительную претензию к разработчику/MS. Ту самую .Net-библиотеку приходится лОжить рядом с исполняемым файлом. Других вариантов не нашел.
← →
Делфией (2010-02-15 15:00) [52]
> Игорь Шевченко © (14.02.10 23:48) [48]
</I
> Даже для 32-х битных приложений под 64-битными системами
> физической памяти памяти больше видно.
>
А для клиентского ПО запредельной памяти и не нужно, а если то про что я выше писал, что не хватает оперативки для нашей АСУДС, ну так все-таки некоторым программистам бы руки кувалдой выровнять нужно. До 2008 г. старая система еще на СМ1420 работала на "Диамс" с диском на сервере в 16мб. и вся база туда свободно умещалась за несколько лет, а сейчас на новой системе после работы пару годков уже незнаемо как базу разместить так как на сервере никаких дисков не хватает.
Отсюда мораль, что огромное и расточительное потребление памяти вероятно не обосновано.
← →
Делфиец (2010-02-15 15:05) [53]
> Плохиш © (15.02.10 00:01) [49]
> > Делфиец (14.02.10 23:14) [46]А мелкий софт по-привычке
> виноват?
А то кто же? Мне есть с чем сравнивать, я еще на СМ-ках работал.
← →
asail © (2010-02-15 15:49) [54]
> Делфией (15.02.10 15:00) [52]
Это все так, конечно... Но зачастую скорость разработки перевешивает требования к системным ресурсам.
Например, можно написать за год продукт, который требует 1Гб оперативки для работы. А мона, чтоб 256Мб требовал, но за 2 года... А мона и чтоб на 16Мб пахал, но 10 лет убить на разработку... На ассемблере... И биться до победного за каждый байт... Вопрос - а нафига?
ИМХО.
← →
Игорь Шевченко © (2010-02-15 16:25) [55]
> До 2008 г. старая система еще на СМ1420 работала на "Диамс"
> с диском на сервере в 16мб. и вся база туда свободно умещалась
> за несколько лет, а сейчас на новой системе после работы
> пару годков уже незнаемо как базу разместить так как на
> сервере никаких дисков не хватает.
Это натурально MS виноват. Только одно непонятно - кто вам мешал и после 2008 года оставаться на CM1420 с диском в 16Мб ?
← →
Дмитрий Белькевич (2010-02-15 16:27) [56]>Это все так, конечно... Но зачастую скорость разработки перевешивает требования к системным ресурсам.
В реальной жизни, массовые продукты (ну разве что кроме игр) не стоит разрабатывать под топовое железо.
← →
Дмитрий Белькевич (2010-02-15 16:30) [57]
> Например, можно написать за год продукт, который требует
> 1Гб оперативки для работы. А мона, чтоб 256Мб требовал,
> но за 2 года...
Мона сделать нормальную архитектуру и сделать 256 мб за год. Ну а если левой ногой делать - то и 8 гиг будет мало.
← →
Кто б сомневался © (2010-02-15 16:33) [58]
> @!!ex © (14.02.10 20:00) [21]
>
> > [19] miek (14.02.10 19:54)
>
> Проблема дельфи не столько в том, что она дорогая... а в
> том что она убогая.
> IDE просто отличная, но сама концепция устарела и не развивается.
>
> Компилятор только под Win и только 32(это во вреемена, когда
> уже практически нельзя купить новый 32 битный комп).
> VCL нормально работает только в однопоточной среде(это во
> времена, когда на конвеер уже поставлены 8 ядерные процессора).
>
>
> Это все и заставило лично меня заняться поиском альтернатив.
> :(
Т.е. по твоему она убогая т.к. нет x64 и однопоточная VCL (что в реальности не существенно - т.к. распаралеливаются свои задачи без проблем).
Вот эти 2 проблемы, т.к. другие настолько не критичны.
И поэтому ты начал искать альтернативу?
Что там за программы то такие? И всем твоим программам реально необходим x64 (именно всей программе, а не какому то модулю из пакета программ?)?
← →
Дмитрий Белькевич (2010-02-15 16:36) [59]Недавно. Перелезли на новые DelphiX. В TDIB добавили статический буфер: FLUTDist: array[0..255, 0..255]. Кажется - мелочь. Результат - на загруженных в TDIB 2000-ах картинок потерялся гиг. Переписал на динамику: array of array of Integer; гиг нашёлся. Почему бы сразу не сделать...
← →
Кто б сомневался © (2010-02-15 16:38) [60]Я сколько игрушек играю, и очень редко попадаются игрушки с exe x64. А ведь прежде всего подобным программам реально нужно x64 для доступа к больши массивам памяти.
Реально редко, - т.к. разработчикам тестировать надо будет в 2 варианта - а это в 1,5 раза больше работы.
← →
@!!ex © (2010-02-15 16:50) [61]> [58] Кто б сомневался © (15.02.10 16:33)
Для меня три критерия сыграли роль:
1) Кроссплатформенность. Так уж сложилось что для меня очень важный критерий. Windows, к счастью, это еще не все компы.
2) Это то, что один из проектов над которым сейчас работаем планируется продавать вместе с сорсами. А сорсы на дельфи сейчас мало кому нужны.
3) Сложно найти адекватных дельфи 3Д программистов. Я вообще на этот критерий плевал.. но сейчас работаем с программистом на С++. И варианты: либо я перехожу на С++, либо он переходит на дельфи... причин переходить на дельфи нет ниодной... хотя я, естественно, сначала хотел все делать на дельфи.. но потом включил мозг.
← →
Кто б сомневался © (2010-02-15 16:56) [62]Ну вот, это совершенно другие критерии. А в плане гуишных прог под win, delphi обыгрывает по скорости и удобству разработки.
> Сложно найти адекватных дельфи 3Д программистов.
А разве в 3d в delphi и С ++ разные технологии используются? Я думал одинаковые, втч и библиотеки.
← →
Дмитрий Белькевич (2010-02-15 16:57) [63]Лично мне не хватает памяти. Я бы не отказался от x64 именно из-за объёмов доступной памяти. Данных бывает реально много и ужать уже нельзя - все разумные меры уже предприняты. Одно время данные даже сжимал "на лету" в памяти - потом отказался. Но куда-то перелазить - нет смысла. Все наработки на Delphi. Многие куски уже начали повторно использоваться. Хорошо изучена. Много стороннего и достаточно дорогого куплено. Жду версию под x64.
Вообще - потенциально можно было бы менеджер памяти переписать под использование AWE, но не думаю, что этим стоит заниматься - будем ждать x64.
Однопоточная VCL особенно не напрягает.
← →
Кто б сомневался © (2010-02-15 17:00) [64]
> И варианты: либо я перехожу на С++, либо он переходит на
> дельфи... причин переходить на дельфи нет ниодной..
Так сложилось исторически, что игры делают на С++. Под этот язык масса шаблонов и модулей уже проработанных.
> Жду версию под x64.
В чем проблема, переписывается какой то модуль под паскалевский x64 компилятор и все.
← →
@!!ex © (2010-02-15 17:01) [65]> [62] Кто б сомневался © (15.02.10 16:56)
> А разве в 3d в delphi и С ++ разные технологии используются?
> Я думал одинаковые, втч и библиотеки.
Нет. Проблема скорее в том, что редко кто занимается графикой на дельфи.
То есть либо специалист в дельфи, либо в графике, редко и то и другое.
Я знаю 4 человека которые профессионально пишут графику на дельфи и все они уже заняты...
а на С++ полно народу.
← →
@!!ex © (2010-02-15 17:02) [66]> [64] Кто б сомневался © (15.02.10 17:00)
> Так сложилось исторически, что игры делают на С++. Под этот
> язык масса шаблонов и модулей уже проработанных.
У меня как раз много шаблонов для дельфи... поэтому сейчас переход весьма болезненный... усугубляется тем, что я на С++ медленней пишу из-за отсутствия опыта.
Но как раз переломный момент и если сейчас остатсья на дельфи, то дальше будет только сложнее.
← →
Игорь Шевченко © (2010-02-15 17:11) [67]
> Сложно найти адекватных дельфи 3Д программистов
Адекватных программистов вообще сложно найти.
← →
Кто б сомневался © (2010-02-15 17:18) [68]
> усугубляется тем, что я на С++ медленней пишу из-за отсутствия
> опыта.
А еще также неудобство и нелюбовь, когда после Delphi с его продуманным прозрачным синтаксисом, C++ кажется каким то монстром, все время возникает вопрос, чем руководствовался человек, который придумывал этот язык, когда придумывал такие сложности и символы в синтаксисе на ровном месте и зачем он это делал. Почему нельзя было просто написать - or, and, итп.
Кем надо быть, чтобы усложнить до && и || где тут логика? Ну что мешало ему написать and вместо &&? Такое чувство что спецом хотели усложнить жизнь.
А вот это >>? Ну что мешало ему написать shr? Ведь скорость восприятия человеком сокращения shr выше.
← →
Eraser © (2010-02-15 17:21) [69]> [18] @!!ex © (14.02.10 19:33)
> Там же прямой доступ к ОС функциям. Типа:
> painter.paintEngine()->getDC() - и вот уже у нас виндовый
> HDC обычный.
можно ли вызывать напрямую API хотя бы как это сделано, к примеру, в .NET? даже если можно, то теряется основной смысл QT, т.к. теряется кроссплатформенность. отсюда вывод, для приложений тесно взаимодействующих с ОС и сильно зависящих от окружения нет особого смысла и заморачиваться с лишними прослойками.
> Компилятор только под Win и только 32
да это существенный недостаток. посмотрим, может летом выпустят обещанный x64.
> VCL нормально работает только в однопоточной среде(это во
> времена, когда на конвеер уже поставлены 8 ядерные процессора)
> .
зачем для GUI несколько потоков?
> [60] Кто б сомневался © (15.02.10 16:38)
> Я сколько игрушек играю, и очень редко попадаются игрушки
> с exe x64. А ведь прежде всего подобным программам реально
> нужно x64 для доступа к больши массивам памяти.
> Реально редко, - т.к. разработчикам тестировать надо будет
> в 2 варианта - а это в 1,5 раза больше работы.
через год-два все будет строго наоборот.
← →
Кто б сомневался © (2010-02-15 17:22) [70]! - почему бы просто не написать not? Откуда к нему вообще пришла эта ассоциация, что восклицательный знак, должен стать not?
← →
Ega23 © (2010-02-15 17:22) [71]Ветку не читал, но осуждаю.
← →
DVM © (2010-02-15 17:22) [72]
> Ну что мешало ему написать and вместо &&?
Потому что короче. Наследие си. Когда памяти были считанные килобайты было важно.
← →
Дмитрий Белькевич (2010-02-15 17:34) [73]Холивар детектид :)
>[61]
Удобнее писать на плюсах - пиши. Для наших условий Делфи подходит идеально - его и используем.
1. Сырцы закрытые и продавать не планируется.
2. Кроссплатформенность в текущих проектах не нужна. Хотя под кпкшник было бы интересно некоторые вещи бесплатно зарелизить. Жду Delphi для телефонов.
3. Есть несколько адекватных программистов под задачи + я сам. Хватает.
← →
DVM © (2010-02-15 17:35) [74]
> Дмитрий Белькевич (15.02.10 17:34) [73]
аналогично
← →
Дмитрий Белькевич (2010-02-15 17:36) [75]
> Когда памяти были считанные килобайты было важно.
Фортран был раньше с и сильно длиннее. И как-то хватало.
← →
Кто б сомневался © (2010-02-15 17:39) [76]
> Потому что короче. Наследие си. Когда памяти были считанные
> килобайты было важно.
Непонятно тогда почему сетевые языки, подхватили эту глупую традицию.
← →
jack128_ (2010-02-15 17:42) [77]
> Потому что короче. Наследие си. Когда памяти были считанные
> килобайты было важно.
хм. а в скомпилированном коде выражение not x занимает меньше, чем !x ?? или имеюттся в виду килобайты для хранения сорцов??
> Кем надо быть, чтобы усложнить до && и || где тут логика?
>
& - это и означает "and". см например названия компаний (Procter & Gamble и тому подобное)
← →
Дмитрий Белькевич (2010-02-15 17:45) [78]Продолжим холивар :)
Чем не нравится дотнет. Собрал в себе два минуса - ограниченную кроссплатформенность. Не знаю, можно ли вообще назвать кросплатформенностью официальную работу только под операционками от MS. И более медленную работу. Кто бы что не говорил, и какие синтетические тесты не приводил - но дотнет работает медленнее.
Посему неясно, зачем он вообще может быть полезен. Под wintel есть нативные среды - Делфи/Билдер/Плюсы. Под кроссплатформенность есть жава.
Единственное - если программа должна работать одновременно и на WM и на обычной W. Но я слабо себе представляю такую программу (сложнее Hello World), которая будет из одних сырцов нормально работать и там и там без учёта в этих сырцах, где сейчас работаем.
Так что моё мнение, что дотнет в текущем состоянии - тупиковая ветвь.
← →
Kerk © (2010-02-15 17:48) [79]& - образовалась от совмещения букв "e" и "t". От латинского "et" - "и"
← →
Дмитрий Белькевич (2010-02-15 17:48) [80]
> & - это и означает "and". см например названия компаний
> (Procter & Gamble и тому подобное)
Почему бы уже тогда не & а &&?
> или имеюттся в виду килобайты для хранения сорцов??
Ну - я думаю это имелось в виду.
← →
DVM © (2010-02-15 17:48) [81]
> jack128_ (15.02.10 17:42) [77]
> или имеюттся в виду килобайты для хранения сорцов??
Имеется в виду процесс создания программы. Она ж должна была где то храниться, компилироваться, редактироваться. Это я где то читал давно, в книге по си какой то.
Вообще, есть много странных вещей, истинная суть которых уже потеряна за древностью лет. Например, почему в Windows Explorer первых версий не было секунд на часах в панели задач. Сейчас это кажется смешным - но из экономии ресурсов.
← →
Кто б сомневался © (2010-02-15 17:51) [82]
> & - это и означает "and".
Нет ну то что автор языка пытался сократить по максимуму это видно сразу, только вот зачем, если это только усложняет чтение.
Ну ^ это xor - никакой логической связи нет.
Но зачем это надо было делать? Нет не из за размера исходников.
Basic придуман был в 63 году, С в 70. Фортран как здесь уже говорили раньше.
← →
Игорь Шевченко © (2010-02-15 17:51) [83]Дмитрий Белькевич (15.02.10 17:45) [78]
>
> Посему неясно, зачем он вообще может быть полезен
> Под кроссплатформенность есть жава.
Ты наверное не в курсе, что .Net был создан в первую очередь, как альтернатива Java, потому что Java придуман не в MS
DVM © (15.02.10 17:22) [72]
> Потому что короче. Наследие си. Когда памяти были считанные
> килобайты было важно.
Совершенно не связано с памятью. Писать меньше - только и всего.
Конструкции получаются охватываемые взглядом и, соответственно, легче понимаемые, если синтаксис в голове держать, а держать его несложно, это вам не APL.
← →
Дмитрий Белькевич (2010-02-15 17:53) [84]
> Вообще, есть много странных вещей, истинная суть которых
> уже потеряна за древностью лет. Например, почему в Windows
> Explorer первых версий не было секунд на часах в панели
> задач. Сейчас это кажется смешным - но из экономии ресурсов.
>
Ну с этим можно согласиться, видел перевод от Гансмокера что ли или еще чей-то блог - вполне логичное объяснение по поводу секунд. Кстати, их до сих пор нет. Но так извращать язык имхо не было никакой критической необходимости. Как уже говорил - Фортран вполне себе и уже давно работал.
← →
Кто б сомневался © (2010-02-15 17:56) [85]
> Конструкции получаются охватываемые взглядом и, соответственно,
> легче понимаемые,
Ниче подобного, наоборот усложняется чтение. Об этом тот же Кладов говорил, бывший сишник в своей книге по КОЛ.
Те же { } хуже чем человеческие begin end, попробуй заметь.
← →
Дмитрий Белькевич (2010-02-15 17:56) [86]
> Ты наверное не в курсе, что .Net был создан в первую очередь,
> как альтернатива Java, потому что Java придуман не в MS
В курсе. Я говорю, что реальной кросс-платформенности нет и, думаю, не будет (из-за политики MS).
← →
Кто б сомневался © (2010-02-15 17:58) [87]Знаете есть такой язык BrainFuck - вот это тот самый усложненный путь.
Легче читать Игорь?
+++++ +++++ initialize counter (cell #0) to 10
[ use loop to set the next four cells to 70/100/30/10
> +++++ ++ add 7 to cell #1
> +++++ +++++ add 10 to cell #2
> +++ add 3 to cell #3
> + add 1 to cell #4
<<<< - decrement counter (cell #0)
]
> ++ . print "H"
> + . print "e"
+++++ ++ . print "l"
. print "l"
+++ . print "o"
>++ . print " "
<< +++++ +++++ +++++ . print "W"
> . print "o"
+++ . print "r"
----- - . print "l"
----- --- . print "d"
> + . print "!"
> . print "\n"
← →
ANB (2010-02-15 18:00) [88]
> Кто б сомневался © (15.02.10 17:56) [85]
Дело вкуса.
1) Мне легче читать и писать на C
2) Как IDE мне делфи нравится намного больше VS (ща сижу и плююсь, т.к. посадили на VS2008 насильно).
3) Так же по опыту знаю, что процент заваленных проектов на C# намного выше, чем на делфи. Собственно, на делфи я ни одного заваленного не видел. А на C# - либо вообще не пошел, либо такое убожество получилось - просто жуть.
← →
@!!ex © (2010-02-15 18:01) [89]> [69] Eraser © (15.02.10 17:21)
> можно ли вызывать напрямую API хотя бы как это сделано,
> к примеру, в .NET? даже если можно, то теряется основной
> смысл QT, т.к. теряется кроссплатформенность. отсюда вывод,
> для приложений тесно взаимодействующих с ОС и сильно зависящих
> от окружения нет особого смысла и заморачиваться с лишними
> прослойками.
Виджеты QT сами по себе более прямые чем VCL.
Понятно, что если есть приложение на дельфи, то просто так брать и переписывать его на Qt эту бессмысленно.
Но вот ваш ROM Viewer, например, прекрасный кандидат на перевод под Qt, потому что ОС зависимых вещей в нем мало(или совсем нет), в отличии от сервера, а кроссплатформенность для него милое дело.
Кстати, что там с Mobile версией? Не в курсе?
← →
Дмитрий Белькевич (2010-02-15 18:02) [90]
> легче понимаемые, если синтаксис в голове держать
Как по мне - то читаемость (в среднем) у плюсов хуже чем у делфи. Если вылизывать сырцы под читаемость - может быть. Но всем ясно, что этим занимаются далеко не все.
Меня лично в плюсах убивает написание идентификаторов. Вот, например, код "в лоб" переведенный на делфи с плюсов:
Var
l__INT__Length : Integer;
l__CHAR__Result,
l__CHAR__Name : String;
l__CHAR__Extension : String[10];
l__INT__ExtStart,
l__INT__k : Integer;
Begin
l__INT__Length := Length(p__PCHAR__Name);
l__INT__ExtStart := 0;
l__INT__k := 0;
//
// make the string to be not less then two chars
//
While l__INT__Length<2 Do Begin
p__PCHAR__Name[l__INT__Length] :="0";
Inc(l__INT__Length);
p__PCHAR__Name[l__INT__Length]:=Chr(0);
End;
10 лет расстрела :)
в коде у рихтера:
SetEvent(g__hEvent),
WaitForSingleObject(g_hFvent, INFINITE);
интересный, конечно, язык. количество подчёркиваний решает :)
← →
@!!ex © (2010-02-15 18:03) [91]> интересный, конечно, язык. количество подчёркиваний решает
> :)
В данном случае это пробелмы венгерской нотации, на которую много грязи льется постоянно, а не языка.
← →
Дмитрий Белькевич (2010-02-15 18:07) [92]
> В данном случае это пробелмы венгерской нотации, на которую
> много грязи льется постоянно, а не языка.
Я не говорю, что именно язык плох. Я говорю, что привычки писать на нём - плохие. Я понимаю, что так уж исторически сложилось и могло сложиться по-другому. Но - так как уже сложилось, то можно это и к минусам языка отнести. Мы же рассматриваем не сферический язык в вакууме, а реальное его применение. В Делфи же не сложилось почему-то. Хотя тоже могло.
← →
Eraser © (2010-02-15 18:14) [93]> [89] @!!ex © (15.02.10 18:01)
> Кстати, что там с Mobile версией? Не в курсе?
ответил по почте.
> Но вот ваш ROM Viewer, например, прекрасный кандидат на
> перевод под Qt
не спорю. возможно. но кроссплатформенная версия будет на джаве, по разным причинам.
> [90] Дмитрий Белькевич (15.02.10 18:02)
> Как по мне - то читаемость (в среднем) у плюсов хуже чем
> у делфи.
это даже в MS осознали, см. C# - там все куда более наглядно и удобно.
← →
Дмитрий Белькевич (2010-02-15 18:16) [94]
> Ты наверное не в курсе, что .Net был создан в первую очередь,
> как альтернатива Java, потому что Java придуман не в MS
Я представляю, в общих чертах - что и почему происходит. Я говорю с позиции разработчика, выбирающего платформу, а не с позиции MS.
← →
@!!ex © (2010-02-15 18:17) [95]> по разным причинам.
По каким, если не секрет?
← →
Дмитрий Белькевич (2010-02-15 18:17) [96]
> выбирающего платформу
Читать - выбирающего среду.
← →
Дмитрий Белькевич (2010-02-15 18:19) [97]
> это даже в MS осознали, см. C# - там все куда более наглядно
> и удобно.
Я даже догадываюсь, кто помог осознать :)
← →
Кто б сомневался © (2010-02-15 18:19) [98]
> > Как по мне - то читаемость (в среднем) у плюсов хуже чем
>
> > у делфи.
>
> это даже в MS осознали, см. C# - там все куда более наглядно
> и удобно.
По сравнению с чем? С Delphi? В плане чего, синтаксиса? Если в плане синтаксиса, значит это маркетинговый отдел постарался.
← →
Игорь Шевченко © (2010-02-15 18:20) [99]Дмитрий Белькевич (15.02.10 18:02) [90]
> Меня лично в плюсах убивает написание идентификаторов. Вот,
> например, код "в лоб" переведенный на делфи с плюсов:
Переводчика не пробовал менять ?
> в коде у рихтера:
в коде у Рихтера все согласно стандарту Microsoft на именование. Практически весь Platform SDK содержит идентификаторы, поименованые таким вот образом.
Ну и что ?
Как ты понимаешь, грамматикой языка ни количество подчеркиваний, ни их наличие, ни регистр символов идентификаторов не регламентируется.
Если кому-то привычно писать с подчеркиваниями, а кому-то непривычно читать - кто им обоим доктор ?
← →
Дмитрий Белькевич (2010-02-15 18:32) [100]
> Переводчика не пробовал менять ?
Это - кусок сырцов примера использования библиотеки StarBurn. Уж не знаю чем они его переводили. Такое чувство - что каким-то софтверным конвертером.
> Как ты понимаешь, грамматикой языка ни количество подчеркиваний,
> ни их наличие, ни регистр символов идентификаторов не регламентируется.
>
Нет. Но на деле получается - что большинство сырцов именно так и написаны.
> Если кому-то привычно писать с подчеркиваниями, а кому-то
> непривычно читать - кто им обоим доктор ?
Ну вот например:
SetEvent(g__hEvent),
WaitForSingleObject(g_hFvent, INFINITE);
Это у Рихтера - опечатка? Или это нормальное написание? Можно ли только по этим двум строкам сказать - код верный или нет? Я, честно говоря, так и не понял.
← →
Eraser © (2010-02-15 18:36) [101]> [95] @!!ex © (15.02.10 18:17)
> По каким, если не секрет?
имеется опыт разработки, java куда более проверенная временем и устоявшаяся платформа, можно запускать прямо через браузер.
← →
DVM © (2010-02-15 18:40) [102]
> SetEvent(g__hEvent),
> WaitForSingleObject(g_hFvent, INFINITE);
Это называется угадай количество подчеркиваний. Вообще уродство эти подчеркивания, не знаю какой это стандарт от MS, но че то в MSDN их не особо встретишь.
← →
Игорь Шевченко © (2010-02-15 18:42) [103]Дмитрий Белькевич (15.02.10 18:16) [94]
> Я представляю, в общих чертах - что и почему происходит.
> Я говорю с позиции разработчика, выбирающего платформу,
> а не с позиции MS.
Позиция разработчика зависит от разрабатываемых программ и области их применения.
← →
Дмитрий Белькевич (2010-02-15 18:48) [104]
> Позиция разработчика зависит от разрабатываемых программ
> и области их применения.
И количества рекламной лапши развешенной на ушах у шефов конторы.
← →
Игорь Шевченко © (2010-02-15 18:48) [105]Дмитрий Белькевич (15.02.10 18:32) [100]
> Это - кусок сырцов примера использования библиотеки StarBurn
Язык здесь как бы и не при чем. Если тебе дадут пример использования библиотеки FooBar на Delphi с подобными идентификаторами, ты, я надеюсь, не станешь делать выводы относительно языка Delphi вообще ?
> Нет. Но на деле получается - что большинство сырцов именно
> так и написаны.
Большинство виденных тобой сырцов, давай уж так говорить. То есть, какое-то подмножество неизвестного размера.
> SetEvent(g__hEvent),
> WaitForSingleObject(g_hFvent, INFINITE);
>
> Это у Рихтера - опечатка? Или это нормальное написание?
> Можно ли только по этим двум строкам сказать - код верный
> или нет? Я, честно говоря, так и не понял.
Как минимум, в приведенном коде используются два разных идентификатора
g__hEvent и g_hEvent. Ошибка это или намеренное введение читателей в заблуждение можно сказать, увидев бумажный вариант (ну или ссылку на него).
Точно так же, как идентификатор типа TForm1 отличается от идентификатора типа TTForm1
← →
Игорь Шевченко © (2010-02-15 18:51) [106]Дмитрий Белькевич (15.02.10 18:48) [104]
> И количества рекламной лапши развешенной на ушах у шефов
> конторы.
Обычно шефы как-то с потенциальными исполнителями находят приемлемый баланс :) Было бы странно иначе, но этот аспект обсуждать неинтересно
← →
@!!ex © (2010-02-15 18:51) [107]> [105] Игорь Шевченко © (15.02.10 18:48)
Пример с TT не совсем корректен, т.к. проблема подчеркивания в том, что они сливаются в один.
← →
Игорь Шевченко © (2010-02-15 18:53) [108]@!!ex © (15.02.10 18:51) [107]
Не понял проблемы
← →
Дмитрий Белькевич (2010-02-15 18:59) [109]
> Пример с TT не совсем корректен, т.к. проблема подчеркивания
> в том, что они сливаются в один.
О чём собственно и речь.
TT или PP лучше чем ___ (это, кстати, сколько подчёркиваний? Чур не копипастить :))
Есть подозрение, что в конкретном случае проблема с распознаванием, т.к. и "hFvent" неверно распознан. Однако - семантика от этого не потерялась. Понятно - что там должна быть буква "E", а не "F". Сколько же там должно быть подчёркиваний - без остальных сырцов не ясно.
← →
Игорь Шевченко © (2010-02-15 19:01) [110]
> Сколько же там должно быть подчёркиваний - без остальных
> сырцов не ясно.
Компилятор подскажет.
← →
DVM © (2010-02-15 19:01) [111]
> Игорь Шевченко © (15.02.10 18:53) [108]
> Не понял проблемы
Неуемное использование данного символа создает проблемы как при чтении чужого кода так и использовании, т.к. визуально 2 __ отличаются от 3 ___ слабо, а некоторые умельцы применяют и 4 ____. Стоит забыть одно подчеркивание и проблемы обеспечены.
← →
Игорь Шевченко © (2010-02-15 19:03) [112]DVM © (15.02.10 19:01) [111]
А причем тут С(++) ? Или это только в этом языке, а в остальных не сливается ? :)
← →
Anatoly Podgoretsky © (2010-02-15 19:09) [113]> Кто б сомневался (15.02.2010 17:18:08) [68]
Они создавали язык для жрецов.
← →
DVM © (2010-02-15 19:11) [114]
> Игорь Шевченко © (15.02.10 19:03) [112]
> А причем тут С(++) ?
си тут не при чем. Я говорю лишь о том что подход с использованием подчеркиваний - плохой.
← →
Anatoly Podgoretsky © (2010-02-15 19:11) [115]> jack128_ (15.02.2010 17:42:17) [77]
А && означает Procter && Gamble
← →
Anatoly Podgoretsky © (2010-02-15 19:13) [116]> Kerk (15.02.2010 17:48:19) [79]
Только эт в английском это @
← →
Игорь Шевченко © (2010-02-15 19:14) [117]DVM © (15.02.10 19:11) [114]
> Я говорю лишь о том что подход с использованием подчеркиваний
> - плохой.
Нормальный. Обычно шрифт фиксированный, и один символ от двух вполне себе отличается. А если человек не может разобрать, сколько в книге с пропорциональным шрифтом подчеркиваний написано, это вовсе не повод обвинять язык/символы идентификаторов/Microsoft в злом умысле.
С тем же успехом он не разберет количество пробелов в символьной константе и уж точно(!) не сможет отличить пробел от табуляции.
← →
Virgo_Style © (2010-02-15 19:16) [118]Я боюсь приведений.
Приведений типов в C++.i = (int)(((TListBox *)Sender)->Items->Objects[1]);
i:=Integer(TListBox(Sender).Items.Objects[1]);
← →
@!!ex © (2010-02-15 19:22) [119]> [118] Virgo_Style © (15.02.10 19:16)
к счастью это решается шаблонами. там более человечее приведением можно сделать.
← →
Anatoly Podgoretsky © (2010-02-15 19:26) [120]> DVM (15.02.2010 19:01:51) [111]
Это от привычки удваивать.
← →
Anatoly Podgoretsky © (2010-02-15 19:27) [121]> DVM (15.02.2010 19:11:54) [114]
Культура языка не отделима от самого языка.
← →
Игорь Шевченко © (2010-02-15 19:31) [122]
> Приведений типов в C++.
в С++ доступен синтаксисint(PListBox(Sender)->Items->Objects[1]);
http://en.wikibooks.org/wiki/C%2B%2B_Programming/Type_Casting
← →
Kerk © (2010-02-15 19:32) [123]
> Anatoly Podgoretsky © (15.02.10 19:13) [116]
>
> > Kerk (15.02.2010 17:48:19) [79]
>
> Только эт в английском это @
Не вижу связи между латинским et и английским at. Ну разве что визуально похожи :)
← →
Anatoly Podgoretsky © (2010-02-15 19:36) [124]> Kerk (15.02.2010 19:32:03) [123]
Скрипач ты ЭТ от ЭНД не отличаешь?
← →
Kerk © (2010-02-15 19:42) [125]
> Anatoly Podgoretsky © (15.02.10 19:36) [124]
Отличаю. "ET" и "AND" - это одно слово, но на разных языках. А "AT" и "AND" - разные слова, но на одном языке.
← →
@!!ex © (2010-02-15 20:00) [126]<offtop>
Сейчас вникаю в идею сигнально/слотового обмена сообщения из Qt.
Это нечто... то чего не хватало для полноценной разработки независимых компонентов в дельфи.
В качестве изучения решил написать небольшой менеджер ресурсов для локальных нужд...
и получается лучше и красивее чем на дельфи.
</offtop>
← →
oxffff © (2010-02-15 20:47) [127]
> @!!ex © (15.02.10 20:00) [126]
Прочитал. Не понял где повод для радости?
Каждый Qt-объект (не только вызуальные элементы!) может генерировать некоторые сигналы, жестко
зашитые в структуру его класса. Сигнал -- это функция, объявленная в специальной секции signals
и не имеющая реализации ("тела") а только передаваемые аргументы. К сигналу объекта (заметьте, не класса) могут быть подключены слоты. Слот -- это всего лишь метод, также объявленный в специальных секциях "slots". Слоты
могут быть доступными (секция "public slots"), защищенными ("protected slots") и
скрытыми ("private slots"). При помощи специального метода connect слот подсоединяется к сигналу.
Небольшой пример:
connect(myValueDetector, SIGNAL(ValueChange( Value a),
myApplicationUpdater, SLOT(onValueChange( Value a ))));
После чего при каждом "испускании" сигнала ValueChange объектом myValueDetector
будет вызываться слот onValueChange объекта myApplicationUpdater.
Плюсы -- к одному сигналу можно подключить несколько слотов.
Минусы -- один слот нельзя использовать для нескольких сигналов (например, для обработки группы кнопок). Сравните с системой событий VCL/CLX -- там как раз всё наоборот.
Можешь почитать реализацию в SAP.
http://help.sap.com/saphelp_nw04/helpdata/en/41/7af4eca79e11d1950f0000e82de14a/frameset.htm
Потом прочитать реализацию в .Net.
Тот самый MulticastDelegate и подумать почему он является объектом кучи.
И что мешает сделать тоже самое в Delphi?
Причем здесь Delphi?
← →
@!!ex © (2010-02-15 20:51) [128]> [127] oxffff © (15.02.10 20:47)
> Минусы -- один слот нельзя использовать для нескольких сигналов
> (например, для обработки группы кнопок). Сравните с системой
> событий VCL/CLX -- там как раз всё наоборот.
Правда чтоли??
Походу у меня сломанная Qt, позволяет привязывать к слоту кучу сигналов. :"(
А как это сделать на дельфи?
← →
oxffff © (2010-02-15 21:05) [129]
> @!!ex © (15.02.10 20:51) [128]
> > [127] oxffff © (15.02.10 20:47)
> > Минусы -- один слот нельзя использовать для нескольких
> сигналов
> > (например, для обработки группы кнопок). Сравните с системой
>
> > событий VCL/CLX -- там как раз всё наоборот.
>
> Правда чтоли??
>
> Походу у меня сломанная Qt, позволяет привязывать к слоту
> кучу сигналов. :"(
> А как это сделать на дельфи?
Плохо отзываешься о Delphi.
http://blogs.embarcadero.com/abauer/2008/08/15/38865
← →
@!!ex © (2010-02-15 21:08) [130]> [129] oxffff © (15.02.10 21:05)
нече так огород...
я не сомневаюсь что можно сделать все, написать свой MOC для дельфи, например.
И переписать все компоненты с поддержкой данного генерика....
Но это не сделано.
И до тех пор, пока сделано не будет - бессмысленно.
← →
oxffff © (2010-02-15 21:20) [131]
> @!!ex © (15.02.10 21:08) [130]
Мне больше интереснее посмотреть на универсальный invoker слотов QT.
Пришли исходник.
← →
@!!ex © (2010-02-15 21:25) [132]> [131] oxffff © (15.02.10 21:20)
Исходник чего?
Он же на уровне Qt реализован и моего понимания кода не хватит чтобы его оттуда выдрать в полном размере.
← →
Игорь Шевченко © (2010-02-15 21:25) [133]
> http://blogs.embarcadero.com/abauer/2008/08/15/38865
А зачем такой огород ?
← →
oxffff © (2010-02-15 21:30) [134]
> @!!ex © (15.02.10 21:25) [132]
> > [131] oxffff © (15.02.10 21:20)
>
> Исходник чего?
> Он же на уровне Qt реализован и моего понимания кода не
> хватит чтобы его оттуда выдрать в полном размере.
Жаль.
← →
oxffff © (2010-02-15 21:37) [135]
> Игорь Шевченко © (15.02.10 21:25) [133]
>
> > http://blogs.embarcadero.com/abauer/2008/08/15/38865
>
>
> А зачем такой огород ?
Например, если желаете прикрепить >1 обработчика вместо одного.
В противном случае вам придется писать некую обертку которая внутри производит вызов в цикле. НО это придется делать для каждого типа функции,процедуры,метода.
← →
oxffff © (2010-02-15 21:43) [136]
> Игорь Шевченко © (15.02.10 21:25) [133]
>
> > http://blogs.embarcadero.com/abauer/2008/08/15/38865
>
>
> А зачем такой огород ?
У .Net в этом отношении преимущество поскольку
Method Implementation Flags
The nonterminal symbol <impl> in the method definition form denotes the implementation
flags of the method (the ImplFlags entry of a Method record). The implementation flags are
defined in the enumeration CorMethodImpl in CorHdr.h and are described in the following list:
• Code type (mask 0x0003):
• cil (0x0000). The default. The method is implemented in common intermediate
language (CIL, a.k.a. IL or MSIL). Yes, I realize that CIL does not sound like a good
abbreviation for those familiar with the innards of the Visual C++ compiler,
because in that area it traditionally means “C intermediate language.” You can use
the il keyword if you don’t like cil. Or don’t use either of them; it is a default flag
anyway.
• native (0x0001). The method is implemented in native platform-specific code.
• optil (0x0002). The method is implemented in optimized IL. The optimized IL is
not supported in existing releases of the common language runtime, so this flag
should not be set.
> • runtime (0x0003). The method implementation is automatically
> generated by the
> runtime itself. Only certain methods from the base class
> library (Mscorlib.dll) carry
> this flag. If this flag is set, the RVA of the method must
> be 0.
← →
@!!ex © (2010-02-15 21:54) [137]> [133] Игорь Шевченко © (15.02.10 21:25)
Вещь замечательная.
Позволяет добиться принципиально нового уровня абстракции при создании компонентов.
Жаль только в дельфи эта штука мертворожденная, поскольку понятно, что никто не будет переделывать компоненты и саму РАД для поддержки этой технологии... а без поддержки основными модулями она бессмысленна.
← →
oxffff © (2010-02-15 21:55) [138]
> Жаль только в дельфи эта штука мертворожденная
Вы врач? :)
← →
Игорь Шевченко © (2010-02-15 21:57) [139]oxffff © (15.02.10 21:37) [135]
Не совсем понимаю - возможность вызвать для обработки одного события несколько процедур с разной сигнатурой ? А зачем ?
← →
Игорь Шевченко © (2010-02-15 21:57) [140]@!!ex © (15.02.10 21:54) [137]
> Вещь замечательная.
> Позволяет добиться принципиально нового уровня абстракции
> при создании компонентов.
Пример был бы более убедителен.
← →
oxffff © (2010-02-15 22:01) [141]
> Позволяет добиться принципиально нового уровня абстракции
> при создании компонентов.
Просто сказочный уровень абстракции.
Welcome to the next level.
← →
oxffff © (2010-02-15 22:05) [142]
> Игорь Шевченко © (15.02.10 21:57) [139]
> oxffff © (15.02.10 21:37) [135]
>
> Не совсем понимаю - возможность вызвать для обработки одного
> события несколько процедур с разной сигнатурой ? А зачем
> ?
Несколько процедур с идентичной сигнатурой.
Просто сейчас вам придется писать идентичный код для разных сигнатур.
.. (a:integer;b:integer)
for proc in Procs do proc(a,b)
.. (a:integer;b:integer;c:integer)
for proc in Procs do proc(a,b,c)
....
← →
Игорь Шевченко © (2010-02-15 22:11) [143]oxffff © (15.02.10 22:05) [142]
> Несколько процедур с идентичной сигнатурой.
Это вроде и без намаза можно сделать, или я опять же чего-то не понимаю.
> Просто сейчас вам придется писать идентичный код для разных
> сигнатур.
Ну да. Это настолько страшно, что отсутствие необходимости писания такого кода выдается за сказочно новый уровень абстракции ?
Все-таки наглядный пример был бы более полезен.
← →
@!!ex © (2010-02-15 22:18) [144]> [138] oxffff © (15.02.10 21:55)
> Вы врач? :)
Я пользователь, который не видит применения данной технологии в дельфи на данный момент времени.
Учитывая что VCL к единому стилю привести не могут, не то что на другую технологию перевести - поддержки со стороны VCL не будет никогда. А значит и возможности для использования тоже, т.к. если мешать обычные события и слот/сигнальные, то мы не упрощения кода добьемся, а усложнения.
Т.к. что не вижу пока будущего у этой технологии в дельфи.
> [140] Игорь Шевченко © (15.02.10 21:57)
Простой пример ничего не покажет, т.к. нет никакой разницы с событиями на мелких задачах, а большой пример я не имею желания делать, т.к. уже спать очень хочу.
Основное различие в том, что мы у объекта пишем не обработчик события, а реакцию на событие.
Разница в том, что обработчик предназначен для обрабатывания конкретного события, конкретного объекта.
А реакция может быть абстрагирована от самого события.
Например, сейчас имеем класс хранящий в себе набор параметров.
Ему нужно реагировать на изменение этих параметров через визуальные компоненты.
Я объявляю слот-реакцию типа dataModified и мне нужно знать изменился какой-то checkbox или в текстовом поле изменили текст, или еще что-то подобное произошло. Просто идет реакция на изменение данных.
При этом checkbox одновременно сообщает хранилищу, что данные изменились и при этом не теряет возможности сообщать другим объектам о том, что на него кликнули.
Понятно, что пример немного кривой, т.к. менять данные хранящиеся в классе напрямую - это неверно.
Но сейчас придумать более правильный пример, спать уже очень хочется.
← →
oxffff © (2010-02-15 22:20) [145]
> Игорь Шевченко © (15.02.10 22:11) [143]
> Ну да. Это настолько страшно, что отсутствие необходимости
> писания такого кода выдается за сказочно новый уровень абстракции
> ?
А для тех кто смотрит сквозь абстракции безусловно это не впечатлит.
Собственно и ничем тут впечатлять. Грубо есть некий способ реагировать на событие нескольким обработчикам(то есть события в контейнере) и есть обобщенный типобезопасный способ их вызова.
>Все-таки наглядный пример был бы более полезен.
Я бы тоже хотел увидеть вход на метауровень.
← →
@!!ex © (2010-02-15 22:21) [146]> [139] Игорь Шевченко © (15.02.10 21:57)
> Не совсем понимаю - возможность вызвать для обработки одного
> события несколько процедур с разной сигнатурой ? А зачем
> ?
Например событие изменения выбранного элементы в списке.
Одному объекту достаточно узнать о самом факте изменения.
Другой объект хочет узнать какой элемент выбран в данный момент.
Важно что не нужно делать несколько событий, чтобы сообщить РАЗНЫМ объекатм о факте изменения.
А разные сигнатуры позволяют инициировать событие с полным списокм параметров, а получатели сами выбирают какие параметры отбросить.
← →
@!!ex © (2010-02-15 22:24) [147]> [141] oxffff © (15.02.10 22:01)
> Просто сказочный уровень абстракции.
> Welcome to the next level.
Ну лично для меня это пока откровение.
Тот уровень взаимодействия что я вижу в большинстве Дельфи проектах(видимо просто не вижу нормальных) очень сильно связывают объекты между собой, что на мой взгляд неправильно и я всегда стремился от этого избавиться.
Сейчас у меня есть такая возможность и это оооочень радует. :)
← →
Игорь Шевченко © (2010-02-15 22:27) [148]@!!ex © (15.02.10 22:21) [146]
> Например событие изменения выбранного элементы в списке.
>
> Одному объекту достаточно узнать о самом факте изменения.
>
> Другой объект хочет узнать какой элемент выбран в данный
> момент.
> Важно что не нужно делать несколько событий, чтобы сообщить
> РАЗНЫМ объекатм о факте изменения.
Я тоже не вижу тут необходимости делать несколько событий, поскольку событие одно - изменение элемента в списке.
← →
oxffff © (2010-02-15 22:31) [149]
> А разные сигнатуры позволяют инициировать событие с полным
> списокм параметров, а получатели сами выбирают какие параметры
> отбросить.
Что то мне это напоминает SAP. Интересно кто у кого содрал.
Собственно магия в словах присутствует. Но ее там нет.
НО!!!
Корретней написать что получатель события реагирует строго на событие с конкретной сигнатурой, но у него есть возможность просто псевдопроигнорировать часть или все параметры. Но это не магия .
Ее здесь нет.
← →
oxffff © (2010-02-15 22:39) [150]
> @!!ex © (15.02.10 22:24) [147]
> > [141] oxffff © (15.02.10 22:01)
> > Просто сказочный уровень абстракции.
> > Welcome to the next level.
>
> Ну лично для меня это пока откровение.
> Тот уровень взаимодействия что я вижу в большинстве Дельфи
> проектах(видимо просто не вижу нормальных) очень сильно
> связывают объекты между собой, что на мой взгляд неправильно
> и я всегда стремился от этого избавиться.
> Сейчас у меня есть такая возможность и это оооочень радует.
> :)
Для того, чтобы связать одни объекты с другими, ну просто задаться такой целью. И здесь multicastdelegate не причем. IMHO.
← →
@!!ex © (2010-02-15 22:40) [151]> [148] Игорь Шевченко © (15.02.10 22:27)
Вот именно. ;)
Вы сейчас привели пример на уровне:
Объеет должен знать о существовании списка.
Так вот: не должен.
Мне чем и нравится то, что я сейчас изучаю - очень четкое отделение визуального представления и внутренней обработки.
Объект не знает и не должен знать что за событие вызвало изменение данных. Элемент в списке выбрали, или файл с данными изменился, или по сети данные пришли.
Есть факт изменения данных, но нет привязки к самому объекту, который данные изменяет.
> [149] oxffff © (15.02.10 22:31)
Да я и не говорил что магия. :)
Просто очень хорошая идея, ИМХО.
P.S.
Все. Пойду спать.
Спасибо всем за дискуссию. Она позволила мне лучше понять весь свалившияйся на меня материал.
← →
Eraser © (2010-02-15 22:42) [152]> [144] @!!ex © (15.02.10 22:18)
не сказал бы что это уж очень хороший подход. получается события логических объектов надо привязывать к UI.
мне больше нравится механизм экшинов в делфи, вот там можно четко разграничить UI и логику, в большинстве случаев.
← →
oxffff © (2010-02-15 22:43) [153]
> Что то мне это напоминает SAP. Интересно кто у кого содрал.
Как говорят наши Пермские коллеги: Это все "Дойчен Солдатен".
Видимо немецкие солдаты являются поклонниками QT.
← →
Anatoly Podgoretsky © (2010-02-15 22:45) [154]> Игорь Шевченко (15.02.2010 22:27:28) [148]
Очередная поделка для ла, то есть не очень опытных программистов.
← →
oxffff © (2010-02-15 22:48) [155]>@!!ex © (15.02.10 22:40) [151]
> Вот именно. ;)
> Вы сейчас привели пример на уровне:
> Объеет должен знать о существовании списка.
>
> Так вот: не должен.
Интересно есть например такое событие как TNotifyEvent.
Где здесь в сигнатуре явное указание инициатора события?
← →
Игорь Шевченко © (2010-02-15 22:57) [156]@!!ex © (15.02.10 22:40) [151]
> Вот именно. ;)
> Вы сейчас привели пример на уровне:
> Объеет должен знать о существовании списка.
>
> Так вот: не должен.
Э...тут я запутался. Есть список, на изменение "выбранного элемента" которого должны быть реакции у каких-то объектов. Эти реагирующие объекты не должны знать о списке ?
← →
xayam © (2010-02-15 23:25) [157]Удалено модератором
← →
картман © (2010-02-16 01:56) [158]
> Есть список, на изменение "выбранного
> элемента" которого должны быть реакции у каких-то объектов.
> Эти реагирующие объекты не должны знать о списке ?
до чего наука дошла, однако)
← →
@!!ex © (2010-02-16 09:46) [159]> [154] Anatoly Podgoretsky © (15.02.10 22:45)
> Очередная поделка для ла, то есть не очень опытных программистов.
Я не видел ни одного нормально проекта на дельфи. везде адское переплетение событие между формами и объектами....
> [155] oxffff © (15.02.10 22:48)
> Где здесь в сигнатуре явное указание инициатора события?
Ну так не умеют же компоненты его генерировать.
> [156] Игорь Шевченко © (15.02.10 22:57)
> Эти реагирующие объекты не должны знать о списке ?
Нет, не должны. Они должны знать о факте изменения выбранного элемента, а не о том, что список(который является визуальным отображение и никак с функциональностью этих объектов не связан) изменился.
← →
pasha_golub © (2010-02-16 10:05) [160]Тут давеча бриффинг по Fulcrum был. Я связан non-disclosure agreement, посему открыто говорить не могу, но есть подозрения, что Винда будет не единственной платформой. :)
← →
Думкин © (2010-02-16 10:07) [161]
> @!!ex © (16.02.10 09:46) [159]
> > [154] Anatoly Podgoretsky © (15.02.10 22:45)
> > Очередная поделка для ла, то есть не очень опытных программистов.
>
>
> Я не видел ни одного нормально проекта на дельфи. везде
> адское переплетение событие между формами и объектами...
> .
Черезчур обще, следовательно не верно.
← →
Делфиец (2010-02-16 11:01) [162]
> Кто б сомневался © (15.02.10 17:18) [68]
</I
> А еще также неудобство и нелюбовь, когда после Delphi с
> его продуманным прозрачным синтаксисом, C++ кажется каким
> то монстром, все время возникает вопрос, чем руководствовался
> человек, который придумывал этот язык, когда придумывал
> такие сложности и символы в синтаксисе на ровном месте и
> зачем он это делал. Почему нельзя было просто написать -
> or, and, итп. Кем надо быть, чтобы усложнить до && и ||
> где тут логика? Ну что мешало ему написать and вместо &&?
> Такое чувство что спецом хотели усложнить жизнь.А вот это
> >>? Ну что мешало ему написать shr? Ведь скорость восприятия
> человеком сокращения shr выше.
>
Ну так все же просто, когда спросили принцессу "Казнить или помиловать?", она на написала казнить, потому что в слове было меньше букв.
Очевидно Страуструб пошел тем же путем ведь "&&" меньше чем "end" и >> меньше чем "shr"
А еще более всего ненавижу "Class->name" писать "->" - это так напрягает постоянно два символа вводить да еще один через [Shift], когда нужно очень быстро писать.
← →
@!!ex © (2010-02-16 11:10) [163]> [162] Делфиец (16.02.10 11:01)
> А еще более всего ненавижу "Class->name" писать "->" -
> это так напрягает постоянно два символа вводить да еще
> один через [Shift], когда нужно очень быстро писать.
А ниче, что в дельфи тоже два символа и один также через шифт? ^.
← →
@!!ex © (2010-02-16 11:15) [164]Можно, конечно, использовать точку в дельфи...
А еще можно использовать нормальные ИДЕ для С++, которые сами заменяют точку на ->
← →
Игорь Шевченко © (2010-02-16 11:31) [165]@!!ex © (16.02.10 09:46) [159]
Ты наверное как-то непонятно объясняешь, поэтому я не совсем понимаю, о чем идет речь. Если список должен рассылать оповещения об изменении элемента, то оповещаемые должны знать, от кого им приходит это оповещение, чтобы узнать, что у отправителя есть выбранный элемент, который изменился, ну и так далее.
← →
Делфиец (2010-02-16 11:40) [166]
> @!!ex © (15.02.10 21:54) [137]
> > [133] Игорь Шевченко © (15.02.10 21:25)Вещь замечательная.
> Позволяет добиться принципиально нового уровня абстракции
> при создании компонентов.
А теперь представте, что у вас в одном из обработчиков БАГ и серьезный, вот вы выкурите по полной догадываясь в каком именно из них. Действительно уж невероятный уровень абстракции.
← →
oxffff © (2010-02-16 11:54) [167]
> @!!ex © (16.02.10 09:46) [159]
>
> > [155] oxffff © (15.02.10 22:48)
> > Где здесь в сигнатуре явное указание инициатора события?
>
>
> Ну так не умеют же компоненты его генерировать.
Что не могут генерировать компоненты?
События?
Или указание инициатора события?
← →
Virgo_Style © (2010-02-16 12:13) [168]
> Можно, конечно, использовать точку в дельфи...
А что, кто-то использует не точку, а^.?
Зачем?
← →
Kerk © (2010-02-16 12:23) [169]
> @!!ex © (16.02.10 09:46) [159]
>
> Я не видел ни одного нормально проекта на дельфи. везде
> адское переплетение событие между формами и объектами...
Не повезло тебе, значит.
← →
Демо © (2010-02-16 14:00) [170]
> Virgo_Style © (16.02.10 12:13) [168]
> > Можно, конечно, использовать точку в дельфи...А что, кто-
> то использует не точку, а ^. ?Зачем?
Потому что указатель. А указатели разыменовывать нужно.
← →
Kerk © (2010-02-16 14:03) [171]Глупо сравнивать синтаксис языка (точка вместо разыменовывания) и функционал IDE (замена точки на ->). Современные IDE вообще много всего умеют, так можно далеко уйти.
← →
@!!ex © (2010-02-16 14:08) [172]> [169] Kerk © (16.02.10 12:23)
> Не повезло тебе, значит.
Я тож так думаю. Покажешь правильный проект?
Сложнее чем калькулятор или блокнот.
← →
Игорь Шевченко © (2010-02-16 14:24) [173]@!!ex © (16.02.10 14:08) [172]
А что, на sourceforge нету правильных проектов ? Или тебе среди местных надо обязательно ?
← →
@!!ex © (2010-02-16 14:27) [174]> [173] Игорь Шевченко © (16.02.10 14:24)
Мне все перебрать в поисках правильных? :)
Вы же видели таки епроекты, ну так и другим почему бы не показать?
← →
@!!ex © (2010-02-16 15:01) [175]Вообще что это я...
Спорю о С++ на форуме Дельфи программистов. :D
Просто хотел сказать, что есть среда сравнимая с дельфи по удобству и возможностям.
Не без недостатков(медленная компиляция и пока менее удобный визуальный редактор), но при этом ИМХО лучшая аьтернатива, чем, например, Lazarus или MSE.
← →
KilkennyCat © (2010-02-16 15:22) [176]
> Вообще что это я...
> Спорю о С++ на форуме Дельфи программистов. :D
Да здесь половина пишет вовсе не в Делфи
← →
Alkid © (2010-02-16 15:29) [177]
> Игорь Шевченко © (16.02.10 11:31) [165]
Обработчик может не знать о конкретном классе списка. Он может знать об абстрактной сущности "Что-то-с-текущим-выбором".
Касаемо множественных подписок на события. Вот у меня тут есть небольшой pet project, там есть пример. В частности: у меня есть набор объектов предметной области, которые организованы в коллекции, которые оргаинзовашны в объект "DomainModel". Каждый объект умеет через события уведомлять об изменении своих свойств. При этом на событие "свойство изменилось" у этого объекта одновременно подписываются:
1. Коллекция объектов, которая аггрегирует эти события в более общее событие "коллекция изменилась".
2. Некоторые другие объекты, бизнес-логика которых требует слежения за изменением свойств объекта.
3. UI.
Т.е. режим в котором событие объекта обрабатывается множеством других объектов у меня - совершенно естественный порядок вещей.
← →
lucent (2010-02-16 15:31) [178]Да, да. Я тоже присоединяюсь к просьбе показать вменяемо спроектированное приложение на Delphi.
Пока же всем своим видом, Delphi производит впечатление <вырезано цензурой>, которое просто поощряет создавать приложения, похожие на <вырезано цензурой>.
Безусловно, приложения похожие на <вырезано цензурой> можно написать на чем угодно. Но почему именно программисты на Delphi, <вырезано цензурой>, чаще всего брезгают писать комментарии? Почему среда не поощряет написание комментариев, как это делают, например, среды для Java или .NET, и даже для C++ есть doxygen, например, который поощряет создавать описание API библиотек, например, автоматически и в унифицированном виде?
Где, <вырезано цензурой>, средства структурной группировки кода, подобно пакетам в Java или пространствам имен в .NET? Даже сиплюсплюсники группируют код с помощью директорий файловой системы, но типичное приложение на Delphi - это большая свалка, в которой невозможно ориентироваться.
А продвинутые средства рефакторинга, учитывающие иерархии классов и сигнатуры методов <вырезано цензурой>, где? А что если проект сложно портировать на Delphi 2006, например, и в 2010 году людям приходится поддерживать его в этом, <вырезано цензурой>, блокноте - Delphi 6, в котором никакого рефакторинга и в помине нет. Ну ладно, если они кроме Delphi 6 ничего не видели, но в противном случае, как им приходится мучиться, беднягам.
А все потому, что Delphi совершенно наплевательски относится к культуре разработки программного обеспечения, заставляя точно так же относиться к ней своих пользователей. Поэтому, проекты, требующие высокой культуры разработки, на Delphi будут просто нежизнеспособны.
← →
Alkid © (2010-02-16 15:42) [179]
> lucent (16.02.10 15:31) [178]
То же самое можно написать про любой язык. Сколько гуано-кода я видел на и С++ и на С#....
← →
Ega23 © (2010-02-16 15:44) [180]C# не видел, но осуждаю.
← →
Alkid © (2010-02-16 15:49) [181]
> Ega23 © (16.02.10 15:44) [180]
Фи, Олег, это ненаучно!
← →
lucent (2010-02-16 15:53) [182]Alkid © (16.02.10 15:42) [179]
Фишка в том, что и C++ и C# используются в местах, где о культуре разработки хоть сколько-нибудь заботятся, поэтому, у разработчиков на этих языках есть откуда черпать благодать.
А Delphi в таких местах не используется. По крайней мере, мне об этом ничего не известно. И код на Дельфи является самым экстрактом, так сказать, вышеозначенной субстанции. А почему она не используется крупными игроками в качестве основного средства разработки, а для автоматизации бухгалтерии в основном? Какие могут быть этому объяснения?
← →
Anatoly Podgoretsky © (2010-02-16 15:54) [183]> lucent (16.02.2010 15:31:58) [178]
Потому что Дельфи позволяет писать самодокументрованые проекты.
← →
Делфиец (2010-02-16 15:55) [184]Никто не исследует причины, пока не нарвется на последствия, множественность обработчиков приведет к неоднозначности толкования, при отладке глюков, думается мне, что глюков великих неизбежать, ведь от ошибок ни кто не застрахован. А потом они откроют еще одну гениальную технологию называется "На каждое событие один обработчик".
Где то подобное уже было это кажется с множественным наследованием, когда долго прходилось выяснять от какогоже наследника наследовался глюк, а в итоге в некоторых языках отказались от множественного наследования. (ну я при это на 100% не утверждаю)
Тоже что писать
with Object1,Object2, Object3 do
begin
//...
end;
а затем выяснять какой объект загнулся от неправильных параметров?
← →
jack128_ (2010-02-16 15:55) [185]ну очевидно потому что для Win приложений выбираются те только языки за которыми стоит MS. То есть сначала C, потом С++, сейчас C#.
← →
Alkid © (2010-02-16 16:01) [186]
> lucent (16.02.10 15:53) [182]
Это очень общие утверждения. Что бы так утверждать, надо обладать нехилой статистикой по разработкам на Delphi, C++ и C#. Я говорю о личном опыте - я видел, как на С++ и С# писалось ТАКОЕ, что волосы дыбом встают. После этого я напрочь не верю утверждениям, типа "на языке Х умнО так, а на языке Y - только тяп-ляп".
← →
Alkid © (2010-02-16 16:04) [187]
> Делфиец (16.02.10 15:55) [184]
У меня есть достаточно большой опыт работы и со множественным наследованием и с множественными делегатами. То, что ты описал там - not an issue. Там есть другие приколы, но ты их не упомянул.
Какой опыт работы с указанными вещами у тебя? Какая у тебя база для обобщения?
← →
Alkid © (2010-02-16 16:05) [188]
> jack128_ (16.02.10 15:55) [185]
С каких это пор за С/С++ стоит MS?
← →
Kerk © (2010-02-16 16:05) [189]C#, вообще, перехватил сейчас пальму первенства у Visual Basic, в том смысле, что теперь это самый популярный язык среди позавчера купивших книжку программистов.
← →
Eraser © (2010-02-16 16:10) [190]> [183] Anatoly Podgoretsky © (16.02.10 15:54)
еще бы убрали пару-тройку основных багов из встроенной системы документирования - цены бы не было ;-)
← →
картман © (2010-02-16 16:16) [191]
> lucent (16.02.10 15:31) [178]
Толстому просто повезло с родным языком, родись он в Индии, строчил бы себе камасутры
← →
jack128_ (2010-02-16 16:24) [192]
> С каких это пор за С/С++ стоит MS?
ну скажем так, она выпускала либы и инструменты заточенные под эти языки. А вот дельфи или там фортран какой нить остались неудел.
← →
Игорь Шевченко © (2010-02-16 16:33) [193]Alkid © (16.02.10 15:29) [177]
> Он может знать об абстрактной сущности "Что-то-с-текущим-
> выбором".
И что же такое "Абстрактная сущность с абстрактным текущим выбором" ? Уж не интерфейс ли ? Уж не базовый ли класс сущностей с текущим выбором ?
И должен ли оповещаемый знать, за какую ногу оповещателя дернуть ? Должен. Как ты тут не абстрагируйся.
> Касаемо множественных подписок на события
Касаемо множества подписок на события все вполне себе огранизуется довольно ясным средствами, списками, массивами, и т.п. а не тем полетом фантазии с ассемблером, которая тут по ссылке промелькнула.
Оно понятнее получается, если что, когда на привычных структурах.
lucent (16.02.10 15:31) [178]
Программу на Фортране можно написать на любом языке.
← →
Virgo_Style © (2010-02-16 16:35) [194]
> Потому что указатель. А указатели разыменовывать нужно.
Зачем? Напомню, речь идет не о "чистых" указателях, а о ListBox->Items и подобных (см. [163]).
← →
oxffff © (2010-02-16 16:50) [195]
> lucent
Без комментариев.
← →
Игорь Шевченко © (2010-02-16 16:53) [196]Virgo_Style © (16.02.10 16:35) [194]
Степень "чистоты" указателей не озвучена
← →
DVM © (2010-02-16 17:03) [197]
> lucent (16.02.10 15:31) [178]
> Я тоже присоединяюсь к просьбе показать вменяемо спроектированное
> приложение на Delphi.
Вменяемо спроектированное с точки зрения кого? Да и критерии вменяемости не озвучены. С моей точки зрения их много. Может вам просто не попадались. Я даже знаю почему, потому что вообще проектов на делфи значительно меньше чем на си. Поэтому в абсолютном исчислении их само собой меньше. Но в относительном вменяемых приложений столько же что и на си.
> Почему среда не поощряет написание комментариев,
Она что их у тебя вырезает? И ставит <вырезано цензурой>? Что значит поощрять?
> но типичное приложение на Delphi - это большая свалка, в
> которой невозможно ориентироваться.
У меня лично все разложено по папкам и классы разнесены по модулям. И структура вообще отличается от предлагаемой по умолчанию. Если на делфи пытается писать куча начинающих, порождая невменяемые проекты то это ни о чем не говорит, кроме как о том что начинающие любят делфи.
> Поэтому, проекты, требующие высокой культуры разработки,
> на Delphi будут просто нежизнеспособны.
Без культурных программистов проекты нежизнеспособны нигде. А делфи тут не причем.
← →
Игорь Шевченко © (2010-02-16 17:14) [198]
> Без культурных программистов проекты нежизнеспособны нигде
Можно и некультурного выдрессировать. Только смысла тратить силы нету
← →
Германн © (2010-02-16 18:09) [199]
> Да, да. Я тоже присоединяюсь к просьбе показать вменяемо
> спроектированное приложение на Delphi.
http://www.ghisler.com/
← →
DVM © (2010-02-16 18:14) [200]
> Германн © (16.02.10 18:09) [199]
к сожалению там исходники недоступны, как и тут: http://www.ritlabs.ru/the_bat/65/
← →
TUser © (2010-02-16 18:42) [201]Мое ламерское имхо такое. Очень приятно, что на джаве есть контроль выхода индекса за границы массива, сразу исключение, очень удобно ошибки ловить. А на делфи нет, неудобно. Зато тут есть var-параметры для простого типа integer (int по-джавости).
Жить можно в любом языке. Можно даже на перле писАть. Даже по-паскалевски. Удобство/неудобство мало отличается в современных языках, если говорить о базовых конструкциях. Трудно найти современный язык, где нет оператора цикла или возможности делить прогу на модули. Кочнечно, без GC плохо, хотя, хз, может это сдерживает от ошибок. И без RTTI, наверное, кому-то хреново, но тоже живут. Я к тому, что языки современные бывают неудобными, но во-первых, не в хлам, а во-вторых, это субъективно.
А посему, все, чем они глобально отличаются, - это удобство, доступность и богатство библиотек, хелпа, факов, форумов. По всем параметрам, кроме хелпа, Делфи явно проигрывает. А в турбо - там и хелп так изуродовали, что держите меня семеро, под МС работают. Не знаю, как в более поздних.
Имхо есть имхо.
← →
Alkid © (2010-02-16 19:01) [202]
> TUser © (16.02.10 18:42) [201]
Пиши на C#! Там есть и контроль выходов за границы и var-параметры для простых типов.
P.S. У нас в конторе за var (т.е. ref)-параметры бьют по голове подсвечником. И правильно делают :)
← →
oxffff © (2010-02-16 19:04) [203]
>Alkid © (16.02.10 19:01) [202]
>
> P.S. У нас в конторе за var (т.е. ref)-параметры бьют по
> голове подсвечником. И правильно делают :)
Приветствую.
А почему?
← →
vuk © (2010-02-16 19:09) [204]to TUser © (16.02.10 18:42) [201]:
> А на делфи нет, неудобно.
{$R+} - не?
← →
Alkid © (2010-02-16 19:21) [205]
> oxffff © (16.02.10 19:04) [203]
Привет.
Считается плохим стилем. Мы стремимся к идеалам ФП где этого можно достичь :) Если функция ко всему прочему будет еще и чистой, т.е. без побочных эффектов, от это вообще круто. ref-, out-параметры допустимы только там, где без них никак. Например, p/invoke и interop функциях. Но их сразу же оборачиваем фасадом, который предоставляет хороший интерфейс.
Если смотреть в более философском смысле - код становится более читаемым и предсказуемым.
← →
Eraser © (2010-02-16 19:21) [206]как ни крути, а под Win32 рисовать GUI с пом. Делфи на порядок удобнее, чем с пом. аналогов, в особенности VS.
← →
Игорь Шевченко © (2010-02-16 19:24) [207]Alkid © (16.02.10 19:21) [205]
Пуристов - давить :)
Зачем себя ограничивать - не понимаю, лучше использовать возможности языка для решения задачи минимальным количеством максимально ясных конструкций.
← →
oxffff © (2010-02-16 19:31) [208]
> Alkid © (16.02.10 19:21) [205]
>
> > oxffff © (16.02.10 19:04) [203]
>
> Привет.
> Считается плохим стилем. Мы стремимся к идеалам ФП где этого
> можно достичь :) Если функция ко всему прочему будет еще
> и чистой, т.е. без побочных эффектов, от это вообще круто.
> ref-, out-параметры допустимы только там, где без них никак.
> Например, p/invoke и interop функциях. Но их сразу же оборачиваем
> фасадом, который предоставляет хороший интерфейс.
>
> Если смотреть в более философском смысле - код становится
> более читаемым и предсказуемым.
Ну тогда почему бы в Вашей конторе отказаться от рекурсии в именованных функций. А воспользоваться комбинатором неподвижной точки fix как в функциональных языках. И например экзистенциальным типом на абстракции данных.
> Мы стремимся к идеалам ФП где этого можно достичь :)
И программируем на императивных.
← →
TUser © (2010-02-16 19:38) [209]
> vuk © (16.02.10 19:09) [204]
Спасибо ... обязательно буду теперь указывать. Надо же как оказывается полезно участвовать в такой ветке!
← →
Alkid © (2010-02-16 19:39) [210]
> Игорь Шевченко © (16.02.10 19:24) [207]
Всех не передавите!
А если серьезно - паттерны и антипаттерны (в широком смысле, не только GoF и ООП) - это те варианты во всем многообразии возможностей, предоставляемых языком, которые признаны хорошими и нехорошими решениями. Чистые функции и иммутабельные структуры - это хороший паттерн, который приносит много хороших пряников.
Однако от пуристов мы тем и отличаемся, что не прем на пролом. Если следование паттерну заводит в тупик, то ему не следуем.
← →
TUser © (2010-02-16 19:41) [211]хз ... я, например, часто пишу
function BlaBlaBla (aaa, bbb, var ccc): boolean;
Смысл в том, что некое действо выполняется, если выполняется то TRUE, и тогда возвращается некое значение в ссс, а иначе - FALSE и в ссс смотреть бесполезно.
Не претенуя на истину, - а что в этом плохого?
← →
Alkid © (2010-02-16 19:46) [212]
> oxffff © (16.02.10 19:31) [208]
> И программируем на императивных.
Ну это как сказать. Вот это императивный код?
private IEnumerable<FieldJoin<TR>> JoinFields<TDataField, TR>(
object instance,
DataTransferObject dto,
Func<MemberInfo, bool> memberPredicate,
Func<MemberInfo, TDataField, FieldJoin<TR>> joinCombinator)
where TDataField : DataField
{
return GetObjectFields(instance, _ => memberPredicate(_))
.Join(GetDtoFields<TDataField>(dto),
_ => Utils.GetFieldName(_),
_ => _.Name,
joinCombinator);
}
С#, кстати, считается мультипарадигменным языком и в нем наблюдается устойчивый тренд в сторону ФП.
← →
oxffff © (2010-02-16 20:14) [213]
> Alkid © (16.02.10 19:46) [212]
>
> > oxffff © (16.02.10 19:31) [208]
> > И программируем на императивных.
>
>
> Ну это как сказать. Вот это императивный код?
Но функциональным он не является. Зачем тогда F#?
← →
Делфиец (2010-02-16 20:14) [214]Ну все как только проект добью на делфи, то пойду изучать C#, а вообще то в нашей конторе SAP внедряют и скоро закроют всё и 1с -ников и все, что работало на оракле и все остальное и будет всёпоглащающий SAP, а нас выпнут наулицу. :(
На кого переквалифицироваться? А то что то кайлом махать не хочется.
← →
Kerk © (2010-02-16 20:17) [215]
> Кочнечно, без GC плохо
Я не доверяю GC почему-то. Мне комфортнее самому память освобождать.
← →
Игорь Шевченко © (2010-02-16 20:22) [216]Alkid © (16.02.10 19:39) [210]
> варианты во всем многообразии возможностей, предоставляемых
> языком, которые признаны хорошими и нехорошими решениями.
> Чистые функции и иммутабельные структуры - это хороший
> паттерн, который приносит много хороших пряников.
Ох уж эти догматики. "Признано".
Цитата прямо напрашивается:
"ОО-языки упрощают абстракцию, возможно, даже слишком ее упрощают. Они поддерживают
создание структур с большим количеством связующего кода и сложными уровнями.
Это может оказаться полезным в случае, если предметная область является
действительно сложной и требует множества абстракций, и вместе с тем такой
подход может обернуться неприятностями, если программисты реализуют простые
вещи сложными способами, просто потому что им известны эти способы и они умеют
ими пользоваться.
Все ОО-языки несколько склонны "втягивать" программистов в ловушку избыточной
иерархии. Чрезмерное количество уровней разрушает прозрачность: крайне
затрудняется их просмотр и анализ ментальной модели, которую по существу
реализует код. Всецело нарушаются правила простоты, ясности и прозрачности,
а в результате код наполняется скрытыми ошибкми и создает постоянные проблемы
при сопровождении.
Данная тенденция, вероятно, усугубляется тем, что множество курсов по
программированию преподают громоздкую иерархию как способ удовлетворения
правила представления. С этой точки зрения множество классов приравнивается
к внедрению знаний в данные. Проблема данного подхода заключается в том, что
слишком часто "развитые данные" в связующих уровнях фактически не относятся
у какому-либо естественному объекту в области действия программы -
они предназначены только для связующего уровня.
Одной из причин того, что ОО-языки преуспели в большинстве характерных для них
предметных областей (GUI-интерфейсы, моделирование, графические средства),
возможно, является то, что в этих областях относительно трудно неправильно
определить онтологию типов. Например, в GUI-интерфейсах и графических средствах
присутствует довольно естественное соотвествие между манипулируемыми
визуальными объектами и классами. Если выясняется, что создается большое
количество классов, которые не имеют очевидного соответствия с тем, что
происходит на экране, то, соотвественно, легко заметить, что связующий уровень
стал слишком большим.
"
Я к чему - про приведенный тобой кусок кода в [212], вроде все слова по отдельности не вызывают непонимания, а в целом - ну напрочь непонятно.
Хорошо, когда абстракция на ладони, а когда абстракция ради абстракции (ну вот мне так по первому впечатлению кажется), получается еще более запутанно для простого неотягощенного программиста.
← →
Alkid © (2010-02-16 20:23) [217]
> TUser © (16.02.10 19:41) [211]
Я не люблю out/ref-параметры потому, что они автоматически приводят к "нечистой" функции (как звучит-то!) и потере всех пряников ФП. Кроме того, наличие out/ref-параметра - это явный code smell. Если функция возвращает два значения, то не занимается ли она двумя разными вещами, которые надо бы разбить на две функции? Функции с out-параметрами плохо подходят для функциональной комбинации. Ну и, наконец, такие функции запутывают код.
← →
Игорь Шевченко © (2010-02-16 20:24) [218]Kerk © (16.02.10 20:17) [215]
> Я не доверяю GC почему-то
то есть, на всяких там перлах и прочих скриптовых языках ты пишешь исключительно под наркозом ? :)
← →
Игорь Шевченко © (2010-02-16 20:27) [219]Alkid © (16.02.10 20:23) [217]
И все-таки давить. Функция вполне может возвращать N параметров и быть при этом максимально простой и ясной в отличие от искусственного нагромождения "объекта параметров" для замены такого вот code-smell :) Да и чем по сути будет отличаться набор параметров от набора свойств объекта параметров в этом случае кроме дополнительного кода - я как-то не понимаю.
← →
Alkid © (2010-02-16 20:30) [220]
> oxffff © (16.02.10 20:14) [213]
> Но функциональным он не является. Зачем тогда F#?
Он является как раз самым что ни на есть функциональным. Это чистая функция высшего порядка - отвечает всем критериям "функциональной функции". То, что она написана на C# ничего не меняет. Функционально программировать можно на любом языке, на котором можно написать чистую функцию. Просто в некоторых языках оставаться в парадигме ФП невыгодно из-за небольшой поддержки такого стиля в языке.
Вот тебе пример ФП на старом добром С:
int sum(int a, int b)
{
return a + b;
}
int mul(int a, int b)
{
return a * b;
}
int summAndMult(int a, int b, int c)
{
return sum(a, mult(b, c));
}
← →
Alkid © (2010-02-16 20:34) [221]
> Игорь Шевченко © (16.02.10 20:22) [216]
Ну, тот кусок кода к ООП не имеет никакого отношения :) А не понятно в нем ничего потому, что он выдран из контекста. И для его понимания надо представлять C# 3.0 и Linq.
Что же касается ООП и прочих "серебряных пуль" - я сам не сторонник превознесения одной парадигмы с презренным отверганием других. И ФП я пиарю не в смысле "срочно все языки запретить и всё переписать на Хаскеле!!!", а пропагандируя то, что я сам, на своем опыте нашел полезным.
← →
Делфиец (2010-02-16 20:43) [222]
> Игорь Шевченко © (16.02.10 20:27) [219]
А дело в том , что вы не одеваете штаны через голову, а они это да - это могут и причем загоняют этим всех в неловкое положение - "вы же ведь так не можете".
← →
Игорь Шевченко © (2010-02-16 20:43) [223]Alkid © (16.02.10 20:34) [221]
Да дело не в ООП в приведенном коде. Уж больно он абстрактно выглядит :)
Про linq слышал, даже видел, даже пользовался, но никак не могу понять, какой в нем великий смысл и панацея.
> И для его понимания надо представлять C# 3.0
Я года три назад сотоварищи пытались попредставлять С# 2.0, то есть, 1.0 мы благополучно проигнорировали, а вот 2.0 решили поосваивать. Худо-бедно, даже больше худо поосваивали, набили шишек по первости, чего-то наваяли, и тут на тебе - linq! C#3.0! мама родная, как же за этим угнаться-то ?
Хорошо тем, кто пишет на простом С без плюсов...
← →
Alkid © (2010-02-16 21:00) [224]
> Игорь Шевченко © (16.02.10 20:27) [219]
> Функция вполне может возвращать N параметров и быть при этом максимально простой и ясной в отличие от искусственного нагромождения "объекта параметров" для замены такого вот code-smell :)
Не спорю, может, конечно. Только обычно этот code smell означает, что функция делает несколько вещей сразу и ее стоит разбить на более простые функции.
> Да и чем по сути будет отличаться набор параметров от набора
> свойств объекта параметров в этом случае кроме дополнительного
> кода - я как-то не понимаю.
Если мы говорим про выходные параметры, то:
1. Иммутабельностью данных. Функция не будет менять состояние неких переменных, данных ей в пользование, а породит объект-результат.
2. Возможностью применения этой функции как аргумента в библиотечных функциях высшего порядка для работы со списками.
Например, есть функцияbool TryProcessValue(T value, out R result);которая пытается обработать результат и возвращает true и result, или false и неопределённое значение в result. Пока, вроде, ничего, кроме того факта, что мы имеем переменную с потенциально неопределённым значением.
Теперь мы хотим взять список значений и сформировать список результатов для тех из них, которые можно обработать функцией. Многие языки поддерживают функции filter (http://en.wikipedia.org/wiki/Filter_(higher-order_function)) и map (http://en.wikipedia.org/wiki/Map_(higher-order_function)). В C# они называются Where и Select. Но как засунуть эту функцию в эти? Никак. И мы пишем в стописяттысячный раз унылый цикл вида:
foreach(var v in MyValueCollection)
{
R result
if(TryProcessValue(v, R))
{
MyResultCollection.Add(R);
}
}
Если бы функция TryProcessValue была представлена в виде двух других функций:
bool CanProcessValue(T value);
R Process(T value);
То весь цикл сверху сжался бы до:MyValueCollection.Where(CanProcessValue).Select(ProcessValue);
Мало того, что этот код короче, он еще и понятнее. В нем гораздо более явно выражено намерение программиста, чем в варианте с циклом. Плюс ко всему он работает с неизменяемыми значениями. Чем это хорошо? Можно быстро и безопасно распараллелить при помощи PLINQ:MyValueCollection.AsParallel().Where(CanProcessValue).Select(ProcessValue) ;
Всего одно добавление и наш код автоматически распараллеливается по количеству ядер. Понятное дело, что в этом мало моей доблести (ребята из MS молодцы), но что бы воспользоваться достижениями других, надо придерживать некоторых стандартов.
Пример не надуманный. Сейчас я пишу проект, в котором подобных задач с обработкой коллекций полным полно.
← →
Alkid © (2010-02-16 21:02) [225]
> Делфиец (16.02.10 20:43) [222]
Не бойся, наш фашизм распространяется только на тех, кто пришел к нам работать :)
← →
Alkid © (2010-02-16 21:05) [226]
> Про linq слышал, даже видел, даже пользовался, но никак
> не могу понять, какой в нем великий смысл и панацея.
Панацеи нет, это удобный инструмент, а не спасение мира :)
> C#3.0! мама родная, как же за этим угнаться-то ?
Следить за тем, что происходит :) Технологии вещь эфемерная. Но если понимать фундаментальные вещи, стоящие за тем же Linq, то его понять совершенно не сложно. Это просто удобное воплощение операций над множествами. В принципе, очень похоже на SQL. Или SQL тоже зря придумали? ;)
> Хорошо тем, кто пишет на простом С без плюсов...
Вот уж увольте меня писать те вещи, которые я пишу, на "простом С". И даже с плюсами.
← →
vuk © (2010-02-16 21:15) [227]to Alkid © (16.02.10 21:00) [224]:
> Только обычно этот code smell означает, что функция делает
> несколько вещей сразу и ее стоит разбить на более простые
> функции.
Предлагаю без потери эффективности разбить на более простые функции что-нибудь типа:function TStringList.Find(const S: string; var Index: Integer): Boolean;
← →
Игорь Шевченко © (2010-02-16 21:19) [228]Alkid © (16.02.10 21:00) [224]
> 1. Иммутабельностью данных. Функция не будет менять состояние
> неких переменных, данных ей в пользование, а породит объект-
> результат.
> 2. Возможностью применения этой функции как аргумента в
> библиотечных функциях высшего порядка для работы со списками.
>
Вот ты все-таки не можешь понять одной простой вещи :) Нет черного и нет белого. Да, функция может возвращать несколько значений, это может вполне естественно и очевидно выглядеть. При этом она специально написана для того, чтобы "менять состояние переменных, выданных ей в пользование". Оно может и подход - городить на каждом шагу объекты, создавать, полагаться на сборщик мусора, что он их когда-нибудь подъест, но есть один тонкий момент - не всегда код с объектами, C#3.0 и linq выглядит проще и очевидней, чем без объектов, c#3.0 и linq
> Только обычно этот code smell означает, что функция делает
> несколько вещей сразу и ее стоит разбить на более простые
> функции.
Банальнейший пример - фукнция двоичного поиска в списке возвращает успех/неуспех и позицию в списке либо для найденного элемента, либо место для вставки нового. Да, она делает несколько (а именно две) вещи одновременно.
Предлагаешь разбить на две функции ? А зачем ?
> То весь цикл сверху сжался бы до:
> MyValueCollection.Where(CanProcessValue).Select(ProcessValue);
>
Ты извини, а что оно делает, эта вот строка кода ? Цикл описанный тобой выше, вполне себе понятен, а вот строка - мне, например, ни разу непонятна.
Alkid © (16.02.10 21:05) [226]
> Следить за тем, что происходит :) Технологии вещь эфемерная.
> Но если понимать фундаментальные вещи, стоящие за тем же
> Linq, то его понять совершенно не сложно. Это просто удобное
> воплощение операций над множествами. В принципе, очень похоже
> на SQL
Я немножко в курсе, что linq похож на убогий SQL, но не понимаю, где его место в процедурных языках. SQL обычно используется миллионами мух для манипуляций с данными, процедурные языки для (грубо говоря), кодирования алгоритмов.
Впрочем, мое непонимание вполне может объясняться, скажем так, не тесным знакомством с linq, но первое впечатление именно такое - а нафига?
← →
Игорь Шевченко © (2010-02-16 21:19) [229]vuk © (16.02.10 21:15) [227]
Так не честно, я пост дольше писал :)
← →
vuk © (2010-02-16 21:22) [230]to Игорь Шевченко © (16.02.10 21:19) [229]:
> Так не честно, я пост дольше писал :)
У нас это называется "у дураков и мысли - одинаковые". :))
← →
Alkid © (2010-02-16 21:22) [231]
> vuk © (16.02.10 21:15) [227]
Заметь, я про эффективность ничего не говорил. Вся красота, о которой я говорю, не очень дружит с производительностью и при необходимости оптимизировать "любой ценой" от нее приходится отказываться. Оптимизация вообще плохо дружит со структурированностью программы, принципом сокрытия информации и разделения обязанностей.
Но ты верно ткнул меня носом и я внесу оговорку - я говорю о задачах, где performance - not an issue.
← →
vuk © (2010-02-16 21:29) [232]to Alkid © (16.02.10 21:22) [231]:
> Вся красота, о которой я говорю, не очень дружит с производительностью
Зато красиво всё до опупения. Вот только отчего-то красивая машина не хочет летать красиво. Не дружит она с полетать... :)
← →
Игорь Шевченко © (2010-02-16 21:30) [233]Alkid © (16.02.10 21:22) [231]
> Вся красота, о которой я говорю, не очень дружит с производительностью
> и при необходимости оптимизировать "любой ценой" от нее
> приходится отказываться.
http://local.joelonsoftware.com/wiki/%D0%9D%D0%B5_%D0%B4%D0%B0%D0%B9%D1%82%D0%B5_%D0%90%D1%81%D1%82%D1%80%D0%BE%D0%BD%D0%B0%D0%B2%D1%82%D0%B0%D0%BC_%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D1%8B_%D0%B2%D0%B0%D1%81_%D0%B7%D0%B0%D0%BF%D1%83%D0%B3%D0%B0%D1%82%D1%8C
Alkid © (16.02.10 21:22) [231]
> Оптимизация вообще плохо дружит со структурированностью
> программы, принципом сокрытия информации и разделения обязанностей.
>
Как это ни странно, в ряде случаев отлично дружит. Особенно если объекты не городить :) Сокрытие информации и разделение обязанностей прекрасно можно реализовать и без ООП, чему опыт исходного кода Unix уже лет 30 с копейками как свидетельствует.
← →
Alkid © (2010-02-16 21:33) [234]
> Игорь Шевченко © (16.02.10 21:19) [228]
Я не говорю о черном и белом :) Я надеюсь ты понял, что про подсвечник - это была шутка. Я говорю о том, с чем я столкнулся на своем опыте и для чего предлагаемые мною паттерны оказались хорошим решением.
> Предлагаешь разбить на две функции ? А зачем ?
Именно потому что делает две вещи. Функция, которая делает что-то одно проще во всех смысла - для написания, для понимания, для отладки и поддержки.
> Ты извини, а что оно делает, эта вот строка кода ? Цикл
> описанный тобой выше, вполне себе понятен, а вот строка
> - мне, например, ни разу непонятна.
Ты либо лукавил, говоря о том, что представляешь себе linq, либо сейчас лукавишь :)
> Впрочем, мое непонимание вполне может объясняться, скажем
> так, не тесным знакомством с linq, но первое впечатление
> именно такое - а нафига?
Да как тебе сказать... Вот все сейчас ругают linq, дескать, нафига он нужен. Но никому не приходит в голову ругать функции map,filter, fold, join, intersect, union и т.п., которые в том или ином виде почти в каждом языке встречаются. А ведь это, по сути, одно и то же :)
← →
Делфиец (2010-02-16 21:37) [235]
> Alkid © (16.02.10 21:02) [225]
> > Делфиец (16.02.10 20:43) [222]Не бойся, наш фашизм распространяется
> только на тех, кто пришел к нам работать :)
Так на заметочку, а где вы работаете? А то когда буду безработным шляться, то быть в курсе о подобных конторах в которых прогеров в шеринги выстраивают ;-)
← →
Игорь Шевченко © (2010-02-16 21:41) [236]Alkid © (16.02.10 21:33) [234]
> Именно потому что делает две вещи. Функция, которая делает
> что-то одно проще во всех смысла - для написания, для понимания,
> для отладки и поддержки.
Это опять религиозные споры. Разумеется, можно написать функцию, которая вычисляет квадратные корни, вычисляет координаты вершин всех звездчатых форм икосаэдра с заданным центром и ребром, и предсказывает погоду в 11 точках планеты - все за один вызов. А можно не писать такую функцию.
И можно написать функцию, которая перебирает массив двоичным поиском один раз, а не два, потому что перебор является центральной частью функциональности, а не возвращение найден/не найден и места, куда вставить заданный ключ двумя отдельными вызовами. То есть, если ты делишь эту фунцию на две, ты дублируешь код, который по цитируемым тобой пророкам является грехом куда как большим, нежели возвращение двух значений :)
> Ты либо лукавил, говоря о том, что представляешь себе linq,
> либо сейчас лукавишь :)
Нет, как ни странно, не лукавлю. Абстрактные имена с толку сбивают. Ну и про тесноту общения с linq я тоже упоминал.
> Но никому не приходит в голову ругать функции map,filter,
> fold, join, intersect, union и т.п., которые в том или
> ином виде почти в каждом языке встречаются. А ведь это,
> по сути, одно и то же :)
Э...в паскале тоже встречаются ? :) join, intersect и union ?
← →
делфиец (2010-02-16 21:56) [237]Кстати в самой windows подобных функций полно, которые возвращают переменные и результат одновременно
QueryServiceStatusEx(HSrv,SC_STATUS_PROCESS_INFO,@SSPRec,SizeOf(SSPRec),dw BytesNeeded)
да почти весь WINAPI так устроен, кстати и это тоже придумали те же умные парни из Microsoft .
← →
TUser © (2010-02-16 22:03) [238]да усе хакеры знают, шо винда отстой ...
← →
Делфиец (2010-02-16 22:08) [239]
> делфиец (16.02.10 21:56) [237]
.... И это им не мешает писать подобные функции и далее в и кроме того даже в новых windows. Вы Alkid © представляете себе, что было бы, если бы эти парни из Microsoft дробили бы все свои подобные функиции на двое?
← →
Leonid Troyanovsky © (2010-02-16 22:18) [240]
> Игорь Шевченко © (16.02.10 21:41) [236]
> центральной частью функциональности, а не возвращение найден/не
> найден и места, куда вставить
Академические размышления на эту тему привели меня когда-то
к варианту, способному примирить две позиции:
функция, не могущая принести результат, возбудит исключение.
Конечно, для некоторых случаев использование оного механизма
может оказаться накладным, но для остальных - оч.наглядно.
Да, и уважаемый Alkid © палку-то перегнул, насчет by Ref,
бо, если у функций нет побочных эффектов, скажем, с
выделением памяти, то чего особенного она в системе изменит.
Заполняем мы буферы в функциях Win32, никто, вроде, не пострадал,
если, конечно, внимательно за размерами следил :)
--
Regards, LVT.
← →
oxffff © (2010-02-16 22:35) [241]
> Alkid © (16.02.10 20:30) [220]
>
> > oxffff © (16.02.10 20:14) [213]
> > Но функциональным он не является. Зачем тогда F#?
>
> Он является как раз самым что ни на есть функциональным.
> Это чистая функция высшего порядка - отвечает всем критериям
> "функциональной функции". То, что она написана на C# ничего
> не меняет. Функционально программировать можно на любом
> языке, на котором можно написать чистую функцию. Просто
> в некоторых языках оставаться в парадигме ФП невыгодно из-
> за небольшой поддержки такого стиля в языке.
>
> Вот тебе пример ФП на старом добром С:
>
> int sum(int a, int b)
> {
> return a + b;
> }
>
> int mul(int a, int b)
> {
> return a * b;
> }
>
> int summAndMult(int a, int b, int c)
> {
> return sum(a, mult(b, c));
> }
Как он может являться функциональным языком, если в нем отсутствует много из разделов
http://fprog.ru/2009/issue3/eugene-kirpichov-elements-of-functional-languages?
Да в нем есть замыкания, анонимные функции, полувывод типов, лямбда выражения. Но где все остальное?
← →
jack128_ (2010-02-16 22:39) [242]
> Да, и уважаемый Alkid © палку-то перегнул, насчет by Ref,
>
> бо, если у функций нет побочных эффектов, скажем, с
> выделением памяти, то чего особенного она в системе изменит.
>
ну по крайней мере в многопоточных программах результат работы функции с ref параметрами непредсказуем..int DoWork(ref int i)
{
return i;
}
{
i = 10;
new Thread(() => {i = 20;}).Start();
MessageBox.Show(DoWork(ref i).ToString());
}
← →
Игорь Шевченко © (2010-02-16 22:40) [243]Leonid Troyanovsky © (16.02.10 22:18) [240]
> Академические размышления на эту тему привели меня когда-
> то
> к варианту, способному примирить две позиции:
> функция, не могущая принести результат, возбудит исключение.
>
http://delphikingdom.ru/asp/viewitem.asp?catalogid=1392#SubSubHeader_2_6_6
← →
Игорь Шевченко © (2010-02-16 22:42) [244]jack128_ (16.02.10 22:39) [242]
К чему подобный пример вопиющей безграмотности ? Или очередная иллюстрация принципа: "Дай дураку член стеклянный, он и член разобьет и руки порежет" ?
← →
Alkid © (2010-02-16 22:56) [245]
> vuk © (16.02.10 21:29) [232]
> to Alkid © (16.02.10 21:22) [231]:
>
> > Вся красота, о которой я говорю, не очень дружит с производительностью
>
> Зато красиво всё до опупения. Вот только отчего-то красивая
> машина не хочет летать красиво. Не дружит она с полетать.
> .. :)
Все аналогии лживы :)
← →
Alkid © (2010-02-16 22:56) [246]
> Делфиец (16.02.10 21:37) [235]
> Так на заметочку, а где вы работаете? А то когда буду безработным
> шляться, то быть в курсе о подобных конторах в которых прогеров
> в шеринги выстраивают ;-)
Не скажу :) Пусть будет сюрпризом
← →
Leonid Troyanovsky © (2010-02-16 23:02) [247]
> Игорь Шевченко © (16.02.10 22:40) [243]
Хе-хе.
function Add: TSomeObject;
begin
// Создание объекта
Result := TSomeObject.Create;
// Настройка объекта
Result.ParentList := SomeList;
// ... и другие свойства
// Добавление его в список
SomeList.Add(Result);
end;
Вроде у АП и на стене высекли: лучшая функция, возвращающая
объект - это конструктор.
А то, что "Очень тяжело: писать хороший код на исключениях"
это, конечно, да. Но, для объектной модели, в конечном счете,
полезней, бо прицел на обработку исключений заставляет
более тщательно подходить к проектированию классов.
--
Regards, LVT.
← →
Alkid © (2010-02-16 23:03) [248]
> Игорь Шевченко © (16.02.10 21:41) [236]
> То есть, если ты делишь эту фунцию на две, ты дублируешь
> код, который по цитируемым тобой пророкам является грехом
> куда как большим, нежели возвращение двух значений :)
Ой ли :) "Дублируемый" код просто становится функцией и не дублируется. Что мешает написать функтор, ищущий позицию для элемента в заданном дереве и использовать его в функциях выборки элемента и модификации дерева?
> Э...в паскале тоже встречаются ? :) join, intersect и union?
Про паскаль не скажу, хотя более чем уверен, что есть библиотеки, реализующие их. Собственно я к чему - весь этот linq - это не более, чем .net-воплощение аппарата работы со множествами, который сам по себе ортогонален языку. Этот аппарат очень полезен, если в программе надо обрабатывать коллекции объектов.
> делфиец (16.02.10 21:56) [237]
> да почти весь WINAPI так устроен, кстати и это тоже придумали те же умные парни из Microsoft .
Это были ДРУГИЕ парни из MS :) Не молодцы. В адрес Win32 не плюнул только ленивый.
> Вы Alkid © представляете себе, что было бы, если бы эти
> парни из Microsoft дробили бы все свои подобные функиции
> на двое?
Да. Получился бы API похожий на юниксовый.
← →
oxffff © (2010-02-16 23:09) [249]
> Alkid © (16.02.10 23:03) [248]
>
> > Игорь Шевченко © (16.02.10 21:41) [236]
> > То есть, если ты делишь эту фунцию на две, ты дублируешь
>
> > код, который по цитируемым тобой пророкам является грехом
>
> > куда как большим, нежели возвращение двух значений :)
>
> Ой ли :) "Дублируемый" код просто становится функцией и
> не дублируется. Что мешает написать функтор, ищущий позицию
> для элемента в заданном дереве и использовать его в функциях
> выборки элемента и модификации дерева?
Все бы здорово, только не хорошо чтобы тяжелый код вызывался по два раза. Там где он очевидно должен вызываться только один раз.
← →
Alkid © (2010-02-16 23:09) [250]
> Leonid Troyanovsky © (16.02.10 22:18) [240]
> Да, и уважаемый Alkid © палку-то перегнул, насчет by Ref,
>
> бо, если у функций нет побочных эффектов, скажем, с
> выделением памяти, то чего особенного она в системе изменит.
By-ref by-refу рознь. Если объект передается по ссылке с запретом на модификацию, то ничего плохого я в этом не усматриваю.
> oxffff © (16.02.10 22:35) [241]
> Да в нем есть замыкания, анонимные функции, полувывод типов,
> лямбда выражения. Но где все остальное?
Ты это про С или С#? В любом случае, писать в функциональном стиле можно и не на функциональном языке. Просто поддержки для такого стиля в нем будет меньше.
← →
Alkid © (2010-02-16 23:11) [251]
> Игорь Шевченко © (16.02.10 21:30) [233]
> http://local.joelonsoftware.com/wiki/%D0%9D%D0%B5_%D0%B4%D0%B0%D0%B9%D1%82%D0%B5_%D0%90%D1%81%D1%82%D1%80%D0%BE%D0%BD%D0%B0%D0%B2%D1%82%D0%B0%D0%BC_%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D1%8B_%D0%B2%D0%B0%D1%81_%D0%B7%D0%B0%D0%BF%D1%83%D0%B3%D0%B0%D1%82%D1%8C
>
Читал-читал.
> Как это ни странно, в ряде случаев отлично дружит. Особенно
> если объекты не городить :) Сокрытие информации и разделение
> обязанностей прекрасно можно реализовать и без ООП, чему
> опыт исходного кода Unix уже лет 30 с копейками как свидетельствует.
Да чего ты к объектам прицепился-то? Я вообще-то не ООП тут продвигаю :)
← →
Alkid © (2010-02-16 23:13) [252]
> oxffff © (16.02.10 23:09) [249]
> > Ой ли :) "Дублируемый" код просто становится функцией
> и
> > не дублируется. Что мешает написать функтор, ищущий позицию
>
> > для элемента в заданном дереве и использовать его в функциях
>
> > выборки элемента и модификации дерева?
>
> Все бы здорово, только не хорошо чтобы тяжелый код вызывался
> по два раза. Там где он очевидно должен вызываться только
> один раз.
Я уже оговорился насчет производительности :) Если стоят приоритетные требования по оптимизации, то они сметают многие принципы структурирования кода.
← →
Игорь Шевченко © (2010-02-16 23:14) [253]Alkid © (16.02.10 23:03) [248]
> Ой ли :) "Дублируемый" код просто становится функцией и
> не дублируется. Что мешает написать функтор, ищущий позицию
> для элемента в заданном дереве и использовать его в функциях
> выборки элемента и модификации дерева?
Я наверное чего-то не понимаю. Функция, приведенная мной и vuk-ом делает два дела - возвращает, найден или нет указанный ключ в массиве, и позицию либо найденного ключа, либо для вставки ключа в массив.
То есть, позиция возвращается в любом случае, найден ключ или не найден.
Ты предлагаешь эту функцию разбить на две - одна для поиска (найден/не найден), другая для вычисления позиции ключа в массиве.
Как ты предлагаешь разбить ?
Исходная функция - вот она:function TStringList.Find(const S: string; var Index: Integer): Boolean;
var
L, H, I, C: Integer;
begin
Result := False;
L := 0;
H := FCount - 1;
while L <= H do
begin
I := (L + H) shr 1;
C := CompareStrings(FList^[I].FString, S);
if C < 0 then L := I + 1 else
begin
H := I - 1;
if C = 0 then
begin
Result := True;
if Duplicates <> dupAccept then L := I;
end;
end;
end;
Index := L;
end;
Leonid Troyanovsky © (16.02.10 23:02) [247]
> Вроде у АП и на стене высекли: лучшая функция, возвращающая
> объект - это конструктор.
Дальше приведенного тобой кода тоже стоит почитать - неплохая статья :)
← →
oxffff © (2010-02-16 23:16) [254]
> > oxffff © (16.02.10 22:35) [241]
> > Да в нем есть замыкания, анонимные функции, полувывод
> типов,
> > лямбда выражения. Но где все остальное?
>
> Ты это про С или С#? В любом случае, писать в функциональном
> стиле можно и не на функциональном языке. Просто поддержки
> для такого стиля в нем будет меньше.
Я про с#. Писать можно только в полуфункциональном стиле.
А вызов чистых функций и функций высших порядков это элементы ФП. Но не ФП.
← →
Игорь Шевченко © (2010-02-16 23:21) [255]Alkid © (16.02.10 23:11) [251]
> Да чего ты к объектам прицепился-то? Я вообще-то не ООП
> тут продвигаю :)
Я может быть тебя не так понял, а разве то, что ты продвигаешь, не является надстройкой над ООП и имеет смысл само по себе ? :)
← →
Leonid Troyanovsky © (2010-02-16 23:37) [256]
> Alkid © (16.02.10 23:09) [250]
> By-ref by-refу рознь.
Значит дело не в by ref.
Держать ссылку на объект можно, скажем, и в поле.
Просто, соглашение такое есть (негласное?):
если мы собираемся только читать (ничего в состоянии системы не меняя), то методом будет функция, а если менять (хотя бы состояние самого объекта) - то процедура.
Геттерам не запрещены побочные эффекты, однако, это, IMHO,
не используют. Ну, или, скажем, не надо использовать.
--
Regards, LVT.
← →
Leonid Troyanovsky © (2010-02-17 00:06) [257]
> Игорь Шевченко © (16.02.10 23:14) [253]
> Дальше приведенного тобой кода тоже стоит почитать - неплохая
> статья :)
Я почитал. Большой материал переварен.
Примеры мне только не очень, бо не надо было регулярные функции
с объектами мешать. Начал бы прямо с конструктора/деструктора,
было б проще объяснять, да и полезней.
--
Regards, LVT.
← →
Alkid © (2010-02-17 00:11) [258]
> Игорь Шевченко © (16.02.10 23:14) [253]
> Я наверное чего-то не понимаю. Функция, приведенная мной
> и vuk-ом делает два дела - возвращает, найден или нет указанный
> ключ в массиве, и позицию либо найденного ключа, либо для
> вставки ключа в массив.
> То есть, позиция возвращается в любом случае, найден ключ
> или не найден.
Тьфу, я перепутал функции этой функции :) Приболел немного, вот потерял внимательность. Я думал, что надо вставлять элемент.
Касаемо приведенной тобой функции: ее проблема не в том, что она делает два дела. Ее проблема в том, что она всегда возвращает индекс, даже если его возврат бессмысленнен. Должно быть так: если искомого элемента нет, то индекс в принципе нельзя получить и использовать. Варианты могут быть разные. Самый распространенный - возврат только индекса с бросанием исключения, если такого нет.
← →
Alkid © (2010-02-17 00:12) [259]
> oxffff © (16.02.10 23:16) [254]
> Я про с#. Писать можно только в полуфункциональном стиле.
> А вызов чистых функций и функций высших порядков это элементы
> ФП. Но не ФП.
Что есть ФП, а что не есть - тема для холиваров. Приведенная тобой статья не является стандартом :)
← →
Alkid © (2010-02-17 00:14) [260]
> Игорь Шевченко © (16.02.10 23:21) [255]
> Я может быть тебя не так понял, а разве то, что ты продвигаешь,
> не является надстройкой над ООП и имеет смысл само по себе
> ? :)
Ты меня не так понял. Я сейчас продвигаю идеи функционального программирования, которое появилось задолго до ООП и имеет, в отличие от ООП, строгую формальную базу. При этом хочу оговориться (а то потом не так поймёте :) ) - я не продвигаю ФП как "серебрянную пулю" и единственно верную парадигму.
← →
Alkid © (2010-02-17 00:18) [261]
> Leonid Troyanovsky © (16.02.10 23:37) [256]
Дело не в by-ref. Дело в модификации переданных параметров. Я утверждаю, что при прочих равных функция, которая не производит модификации параметров (как и других side-effect`ов) лучше, чем аналогичная по смыслу функция, которая опирается на side-effect`ы и/или изменение параметров. Причем модификацию параметров я считаю бОльшим злом, чем другой побочный эффект.
Если же надо вернуть несколько значений (и это оправдано! Помним о code-smell), то лучше использовать другие средства - структуры, кортежи. Если они есть в языке, конечно.
← →
Leonid Troyanovsky © (2010-02-17 00:39) [262]
> Alkid © (17.02.10 00:18) [261]
> на side-effect`ы и/или изменение параметров. Причем модификацию
> параметров я считаю бОльшим злом, чем другой побочный эффект.
А мне большим злом представляется другие побочные эффекты,
особенно, если они еще и припрятаны.
Ну, а против модификации параметров возражать не буду,
если это простые типы (Integer в т.ч.).
Возвращаемые результатом структуры не люблю, они тревожат
мое подсознание (что со всем этим добром делать?).
А если за ними стоит выделение памяти - считаю такой возврат недопустимым.
Допустим, что Дельфи может вернуть, скажем, TStrings.
Но, я такую функцию писать не буду.
Это будет procedure FillStrings(Strings: TStrings)
--
Regards, LVT.
← →
oxffff © (2010-02-17 00:58) [263]
> Alkid © (17.02.10 00:18) [261]
>
> > Leonid Troyanovsky © (16.02.10 23:37) [256]
>
> Дело не в by-ref. Дело в модификации переданных параметров.
> Я утверждаю, что при прочих равных функция, которая не
> производит модификации параметров (как и других side-effect`ов)
> лучше, чем аналогичная по смыслу функция, которая опирается
> на side-effect`ы и/или изменение параметров. Причем модификацию
> параметров я считаю бОльшим злом, чем другой побочный эффект.
>
А в чем же этот эффект проявляется?
Здается мне что он окажет некое воздействие на правила B и N редукции термов и сведет на нет или крайне усложнит алгоритм мемоизации.
Или засада в другом?
← →
oxffff © (2010-02-17 01:05) [264]>Alkid ©
Насчет имутабильности переменнных. Мне это знакомо с точки зрения теории типов. Где изменчивость оказывает сильное влияния на диапазон подтипов. Но это из другой области.
← →
Германн © (2010-02-17 01:12) [265]Вот уж не ожидал такого обсуждения. :)
← →
vuk © (2010-02-17 01:13) [266]to Alkid © (17.02.10 00:11) [258]:
> Ее проблема в том, что она всегда возвращает индекс, даже
> если его возврат бессмысленнен.
А вот нифига. Если элемент не найден, то индекс в этой функции все равно имеет смысл.
← →
Petr V. Abramov © (2010-02-17 01:14) [267]
> Leonid Troyanovsky © (17.02.10 00:39) [262]
> Возвращаемые результатом структуры не люблю, они тревожат
> мое подсознание (что со всем этим добром делать?).
> А если за ними стоит выделение памяти - считаю такой возврат
> недопустимым.
считай, но не огульно :)
главное, соблюдать принцип "кто ужинает, девушку, тот ее и танцует", соотвественно, кто память выделяет, тот ее и освобождает. Если новая структура передается куда-то дальше по ходу API, меньше ошибок из серии "за был освободить ltDmMessage, которое в структуре стоит 25-м и вообще for future use и вообще ради лулзов". CloseLtHandle и забыл.
При условии незабывания вызова CloseLtHandle, еснно, но этот случай требует лечения с непредсказуемым (лечения) результатом.
← →
Германн © (2010-02-17 01:16) [268]Удалено модератором
← →
Petr V. Abramov © (2010-02-17 01:39) [269]Удалено модератором
← →
Германн © (2010-02-17 02:01) [270]Удалено модератором
← →
Petr V. Abramov © (2010-02-17 02:09) [271]Удалено модератором
← →
Германн © (2010-02-17 02:18) [272]Удалено модератором
← →
Alkid © (2010-02-17 05:17) [273]
> vuk © (17.02.10 01:13) [266]
> А вот нифига. Если элемент не найден, то индекс в этой функции
> все равно имеет смысл.
Опять моя внимательность меня подводит :(
← →
Alkid © (2010-02-17 05:19) [274]
> Leonid Troyanovsky © (17.02.10 00:39) [262]
Можно поподробнее объяснить, почему против возврата сложных типов из функций?
← →
Alkid © (2010-02-17 05:28) [275]
> oxffff © (17.02.10 00:58) [263]
> Здается мне что он окажет некое воздействие на правила B
> и N редукции термов и сведет на нет или крайне усложнит
> алгоритм мемоизации.
> Или засада в другом?
Ну ты и загнул :) Есть и более прозаические причины, о которых я уже упоминал. В конце концов простое правило, что функция не трогает свои параметры, а всю информацию, которую хочет вывести, выводит через возвращаемое значение, банально упрощает понимание кода. Ну и, естественно, если функция модифицирует что-то нелокальное, то вся декларативность, ФП и прочие пряники идут лесом.
Те материи, которые ты затрагиваешь, для индустриальных языков ещё далеки. А я сейчас говорю о практике разработки, а не о построении коммунизма :)
← →
Kerk © (2010-02-17 09:26) [276]
> Игорь Шевченко © (16.02.10 20:24) [218]
>
> Kerk © (16.02.10 20:17) [215]
>
> > Я не доверяю GC почему-то
>
> то есть, на всяких там перлах и прочих скриптовых языках
> ты пишешь исключительно под наркозом ? :)
Приходится с этим мириться :)
Но при мысли об этом испытываю дискомфорт.
← →
Игорь Шевченко © (2010-02-17 14:03) [277]Alkid © (17.02.10 00:11) [258]
> Должно быть так: если искомого элемента нет, то индекс
> в принципе нельзя получить и использовать
Нет, не должно быть так. Почитай внимательно. Функция ВСЕГДА возвращает индекс, либо найденного элемента, либо места, куда надо вставить элемент.
← →
Leonid Troyanovsky © (2010-02-17 18:07) [278]
> Alkid © (17.02.10 05:19) [274]
> Можно поподробнее объяснить, почему против возврата сложных
> типов из функций?
Структуры неудобно.
Вместо if f(x) или case of f(x) нужно что-то типа with f(x).
Присваивать локальной переменной ради того, чтобы
воспользоваться результатом if p.y? Лишние движения.
Кроме того, структуры редко когда нужны сами по себе,
обычно они идут вкупе с буфером, стримом.
Про классы я уже говорил. Остаются String & Variant.
Ну, это кто как любит, только не забывать про IsMultithread.
А честные параметры Int*, Bool*, Float &etc и даже статические
массивы - почему бы и нет? Возвращаемый функцией
результат лучше их только тем, что лежит в регистре.
Лучше это, конечно, если это не глобальные переменные.
Ну, и, во-ще, если есть нечто более сложное, оно должно быть
в классе, знающем о всех его особенностях, бо глобальные функции
и процедуры могут быть полезны лишь для простых типов.
--
Regards, LVT.
← →
vuk © (2010-02-17 18:27) [279]to Leonid Troyanovsky © (17.02.10 18:07) [278]:
> Структуры неудобно.
Не согласен, если нужно из функции вернуть результат, который сложнее, чем простейший тип, то не вижу никаких проблем, чтобы использовать структуры.
> Присваивать локальной переменной ради того, чтобы
> воспользоваться результатом if p.y? Лишние движения.
Это удобнее, чем передавать кучу параметров через var или out которые все равно придется где-то в локальных переменных хранить.
← →
Leonid Troyanovsky © (2010-02-17 18:39) [280]
> Petr V. Abramov © (17.02.10 01:14) [267]
> и танцует", соотвественно, кто память выделяет, тот ее и
> освобождает.
Мой алгоритм проще запомнить: если хочешь потанцевать,
то для начала накорми. Память распредели, определи локальные
переменные для параметров и т.д. и т.п.
{MS не зря API так строил, и вовсе не потому, что там, скажем, засели
враги ООП или ФП, или просто двоечники, а что подругому было б хуже}
Т.е., выделяется и освобождается все в одном процедурном блоке,
так и следить легче за парами New/Dispose, Create/Free, да и finally будет
на месте.
Ну, а тому, кто забывает CloseHandle, надо потихоньку, понемножку
где-нибудь что-нибудь отрывать, пока, гад, не научится.
--
Regards, LVT.
← →
Leonid Troyanovsky © (2010-02-17 18:46) [281]
> vuk © (17.02.10 18:27) [279]
> Это удобнее, чем передавать кучу параметров через var или
> out которые все равно придется где-то в локальных переменных
> хранить.
А структура не в локальных хранится?
Ну, и напишу функцию f(var s: TSruct): Boolean
Да и кто говорил про "много", я лишь про массив :)
--
Regards, LVT.
← →
vuk © (2010-02-17 18:59) [282]to Leonid Troyanovsky © (17.02.10 18:46) [281]:
> Ну, и напишу функцию f(var s: TSruct): Boolean
Если возврат boolean не нужен, то, как мне кажется, было бы логичным писать:function GetSomething:TStruct;
вместоprocedure GetSomething(var s: TStruct);
Для понимания первое, на мой взгляд, проще и логичнее. Плюс в некоторых случаях позволит обойтись без локальных переменных.
← →
Leonid Troyanovsky © (2010-02-17 19:08) [283]
> vuk © (17.02.10 18:59) [282]
> procedure GetSomething(var s: TStruct);
Если не нужен Boolean можно взять результатом у оной структуры
нечто самое главное (для дальнейшей обработки) простого типа.
В некоторых случаях позволит обойтись без анализа всей структуры.
--
Regards, LVT.
← →
Игорь Шевченко © (2010-02-17 19:11) [284]vuk © (17.02.10 18:59) [282]
А был бы сборщик мусора - и объекты можно было бы возвращать из функций без локальных переменных. То есть, возвращать-то можно и сейчас, только запоминать надо, чтобы грохнуть не забыть
← →
vuk © (2010-02-17 19:58) [285]to Leonid Troyanovsky © (17.02.10 19:08) [283]:
> Если не нужен Boolean можно взять результатом у оной структуры
> нечто самое главное (для дальнейшей обработки) простого
> типа.
> В некоторых случаях позволит обойтись без анализа всей структуры.
>
Зависит от конкретного случая, но отказываться в принципе от возврата функциями сложных типов смысла не вижу.
to Игорь Шевченко © (17.02.10 19:11) [284]:
> То есть, возвращать-то можно и сейчас, только запоминать
> надо, чтобы грохнуть не забыть
>
Так это понятно. С другой стороны, если будет оговорено, что функция возвращает, некий объект, за который ответственность дальше несет вызывающая сторона, то это тоже ничего страшного. Название только функции соответствующее дать - и всё.
То есть примерно так:
GetSomeObject - вызывающая сторона ответственности за время жизни не несет
CreateSomeObject - вызывающая сторона несет ответственность за время жизни
Конечно, второй случай - некий вариант альтернативного конструктора и в этом смысле применение такой функции ничем не хуже обычного вызова конструктора. В идеале, оно, конечно, может быть реализовано добавлением конструктора, но не всегда есть возможность/смысл расширять класс.
← →
Игорь Шевченко © (2010-02-17 20:04) [286]
> Название только функции соответствующее дать - и всё.
RtlActivateActivationContextUnsafeFast
← →
Вася (2010-02-17 20:17) [287]
> Игорь Шевченко © (17.02.10 19:11) [284]
>
> vuk © (17.02.10 18:59) [282]
>
> А был бы сборщик мусора - и объекты можно было бы возвращать
> из функций без локальных переменных. То есть, возвращать-
> то можно и сейчас, только запоминать надо, чтобы грохнуть
> не забыть
Если каждый метод будет возвращать ссылку на Self, то можно и не запоминать
CreateSomeObject.Method1.Method2.Method3.Free;
← →
Игорь Шевченко © (2010-02-17 20:20) [288]Вася (17.02.10 20:17) [287]
Это че ?
← →
Вася (2010-02-17 20:32) [289]
> Игорь Шевченко © (17.02.10 20:20) [288]
>
> Вася (17.02.10 20:17) [287]
>
> Это че ?
>
function TSomeObject.Method1: TSomeObject;
begin
...
Result:=Self;
end;
← →
картман © (2010-02-17 20:35) [290]
> Вася (17.02.10 20:32) [289]
шикаааааааааарно)))
← →
GrayFace © (2010-02-17 21:00) [291]Alkid, в озвученных условиях подход разделения на 2 функции абсолютно верен, но к "более философскому смыслу" он не относится. Если в проекте не используется активно Linq или подобное, то кому сдался функциональный стиль? В часности, в Delphi он никаким боком не нужен.
Модифицируемые параметры могут "пахнуть" только когда их много.
Leonid Troyanovsky © (16.02.10 23:37) [256]
Геттерам не запрещены побочные эффекты, однако, это, IMHO,
не используют. Ну, или, скажем, не надо использовать.
proxy!
Вася (17.02.10 20:17) [287]
CreateSomeObject.Method1.Method2.Method3.Free;
Напоминает то, как я в Луа структуры объявляю. Типа,
define
.int("x")
.int("y")
.int("z")
← →
vuk © (2010-02-17 21:21) [292]to Вася (17.02.10 20:17) [287]:
> CreateSomeObject.Method1.Method2.Method3.Free;
"а я бы ответил матом" (с) не я
:))
to Игорь Шевченко © (17.02.10 20:04) [286]
> RtlActivateActivationContextUnsafeFast
Вот умеешь ты удачный пример найти. Прям уважаю! :))
← →
Eraser © (2010-02-18 00:40) [293]> [284] Игорь Шевченко © (17.02.10 19:11)
with GetSomething() do
try
..
finally
Free;
end;
хотя да, понятнее конечно через переменную, обычно так и делаю.
← →
Германн © (2010-02-18 00:51) [294]
> хотя да, понятнее конечно через переменную, обычно так и
> делаю.
>
Добавлю и свою копейку. Я уже об этом говорил.
Не понимаю почему нет легального способа выполнить такой код:var
List : TList;
...
...
procedure CreateMyClassAndAddToList;
begin
with TMyClass.Create(nil) do try
...
List.Add(что-то, что является адресом того, что было создано в with);
finally
Free;
end;
end;
← →
oxffff © (2010-02-18 00:56) [295]Вот что нам предлагает разработчик компилятора Delphi
http://blog.barrkel.com/2010/01/one-liner-raii-in-delphi.html
← →
Anatoly Podgoretsky © (2010-02-18 09:43) [296]> Германн (18.02.2010 00:51:54) [294]
Так ты же сам отказался в пользу анонимных переменных
← →
jack128_ (2010-02-18 09:54) [297]
> Вот что нам предлагает разработчик компилятора Delphi
>
> http://blog.barrkel.com/2010/01/one-liner-raii-in-delphi.
> html
хе. Я всегда считал, что FreeOnExit - это хак. Ну раз разрабы разрешили, значит можно пользоваться.
← →
vuk © (2010-02-18 10:58) [298]to Германн © (18.02.10 00:51) [294]:
> Не понимаю почему нет легального способа выполнить такой
> код:
Можно было бы решить при помощи хелпера для TObject, но его использование убъет возможность использования других хелперов, что не есть гуд.
← →
jack128_ (2010-02-18 11:00) [299]
>
> Можно было бы решить при помощи хелпера для TObject
да, хелперы конечно удобны, но не доделаны до конца. extention-методы C# гораздо удобнее.
← →
vuk © (2010-02-18 11:05) [300]to jack128_ (18.02.10 11:00) [299]:
Ну... Я хелперами пользуюсь. Вроде нормально.
← →
jack128_ (2010-02-18 11:27) [301]
> Ну... Я хелперами пользуюсь. Вроде нормально.
ну сам же только что в [298] озвучил серьезное ограничение хелперов
ЗЫ я тоже использую их, но это не значит, что их нельзя сделать лучше
← →
Игорь Шевченко © (2010-02-18 11:53) [302]jack128_ (18.02.10 11:00) [299]
> да, хелперы конечно удобны, но не доделаны до конца
Тема конца не раскрыта
← →
vuk © (2010-02-18 12:13) [303]А еще можно такую ботву намутить:
type
TInstanceRef<T> = record
Instance: T;
constructor Create(AInstance: T);
end;
constructor TInstanceRef<T>.Create(AInstance: T);
begin
instance := AInstance;
end;
--------------
with TInstanceRef<TSomeObject>.Create(TSomeObject.Create) do
try
Instance.DoSomething;
finally
Instance.Free;
end;
Правда, на мой взгляд, для доступа к ссылке на экземпляр это уже чересчур как-то. Проще уж переменную завести и не компостировать мозг.
← →
Leonid Troyanovsky © (2010-02-18 13:18) [304]
> Германн © (18.02.10 00:51) [294]
> Добавлю и свою копейку. Я уже об этом говорил.
> Не понимаю почему нет легального способа выполнить такой
> код:
Потому, что твой List будет полон инвалидными ссылками.
Для самопознания класс снабжается довеском:
type
TMySKClass = class (TMyClass)
private
function This: TMySKClass;
end;
function TMySKClass.This;
begin
Result := Self;
end;
Написать же 2 строки не влом, если далее, все равно,
его динамически создавать?
А не включили такую функцию (поле) в генофонд, бо оверхед.
Я уже об этом говорил ;)
--
Regards, LVT.
← →
GrayFace © (2010-02-18 13:24) [305]oxffff © (18.02.10 0:56) [295]
http://blog.barrkel.com/2010/01/one-liner-raii-in-delphi.html
О! В Delphi появились замыкания?
← →
jack128_ (2010-02-18 14:09) [306]а 2009ой еще. и дженерики. тока работоспособность этого дела сомнения вызывает..
Страницы: 1 2 3 4 5 6 7 8 вся ветка
Форум: "Прочее";
Текущий архив: 2010.08.27;
Скачать: [xml.tar.bz2];
Память: 1.48 MB
Время: 0.087 c
