Форум: "Прочее";
Текущий архив: 2014.08.17;
Скачать: [xml.tar.bz2];
Вниз
Вот говорят, что дельфи не умирает Найти похожие ветки
← →
Пит (2014-01-17 19:36) [0]Разве не очевидно обратное, просто даже судя по этому форуму?
Новых лиц - ноль, старички потихоньку сваливают. Кстати, интересно - а на королевстве такие же тенденции, просто я туда не заглядываю, но интересно, это вроде самый популярный дельфи-проект русский.
← →
Pavia © (2014-01-17 19:43) [1]
> Разве не очевидно обратное, просто даже судя по этому форуму?
Эх молодёжь. Каждые 5 лет молодёшь создает новый форум куда и кочуют. Точно также и в лесу где грибы там белки и прочие грузуны. А заними и хищники.
Между прочим новых лиц тут полно.
← →
Пит (2014-01-17 19:46) [2]И на какой же форум в настоящее время скочевали дельфийцы?
← →
Ega23 © (2014-01-17 19:48) [3]sql.ru
← →
Inovet © (2014-01-17 20:03) [4]> [3] Ega23 © (17.01.14 19:48)
> sql.ru
Там «потрепаться» нет.
← →
Inovet © (2014-01-17 20:07) [5]> [4] Inovet © (17.01.14 20:03)
> Там «потрепаться» нет.
Есть же
http://www.sql.ru/forum/pt
Тогда умирает.
← →
картман © (2014-01-17 20:18) [6]
> Вот говорят, что дельфи не умирает
>
> Пит (17.01.14 19:36)
>
> Разве не очевидно обратное, просто даже судя по этому форуму?
>
а какая разница? Пиши, да пиши себе, делов-то
← →
Ega23 © (2014-01-17 20:18) [7]
> Там «потрепаться» нет.
ПТ. Но там адЪ, Израиль и срань пидовья.
← →
Inovet © (2014-01-17 20:27) [8]> [7] Ega23 © (17.01.14 20:18)
А, ну тогда не умирает.
← →
alexdn © (2014-01-17 20:32) [9]Бодро как то умирает, ХЕ2, ХЕ3, ХЕ4, ХЕ5.. Или это агония?
← →
Kerk © (2014-01-17 21:05) [10]Ну умер или не умер, дальше-то что? Ты с таким постоянством эту тему поднимаешь, что складывается впечатление будто Delphi твой родственник.
Цель какова?
Или тебе нужно персональное разрешение писать на C# или что там сейчас у автоматизатороинтеграторов модно? Разрешаю.
← →
Kerk © (2014-01-17 21:08) [11]Я кстати не знаю ни одного популярного программерского форума, который бы не сбавил обороты за последние 5-7 лет. Вот эту тему было бы интереснее обсудить. Думаю, дело в том, что интернет изменился. Раньше с вопросами ходили на форумы, а теперь и stackoverflow хватает. Раньше какие-то свои соображения писали на форумах, а теперь в блогах. Не говоря уже о соцсетях, которых тогда не было. И так далее.
← →
Inovet © (2014-01-17 21:21) [12]> [11] Kerk © (17.01.14 21:08)
> Вот эту тему было бы интереснее обсудить.
Поддерживаю. Давайте обсуждать. Программирование умирает.
← →
Стенка © (2014-01-17 21:25) [13]Все умирает.
← →
Anatoly Podgoretsky © (2014-01-17 21:25) [14]> Ты с таким постоянством эту тему поднимаешь, что складывается впечатление будто Delphi твой родственник.
Наследство делить
← →
AlexDn © (2014-01-17 21:36) [15]> Inovet © (17.01.14 21:21) [12]
> Поддерживаю. Давайте обсуждать. Программирование умирает.
Общение умирает. А веб программирование живёт себе..
← →
Пит (2014-01-17 21:43) [16]>Я кстати не знаю ни одного
>популярного программерского
>форума, который бы не сбавил
>обороты за последние 5-7 лет.
Интересная тема. Не наблюдал, но вполне может быть. Чем это можешь объяснить?
Что все форумы подмял под себя stackoverflow - вряд ли. Соц сети - вряд ли, нет там проф обсуждений, блоги конечно да в какой то степени..
Ты говоришь о русском умирании? Может народ язык выучил - привет гугл транслейт - и за бугром тусуется?
Хабр всех подмял?
Или ит загибаецо? Тоже вариант, как то за последние года особо нового ничего, а старое все перетерли. Хороший продукт уже не столько техника, сколько ресурсы, позиционирование, управление?
← →
ухты (2014-01-17 21:53) [17]что-то интересное выносят на обсуждение очень редко, а школоте по 100500 кругу писать одно и тоже, про то что делать с AV или подобное, не интересно никому
← →
Inovet © (2014-01-17 21:53) [18]> [10] Kerk © (17.01.14 21:05)
> что там сейчас у автоматизатороинтеграторов модно?
В тендере или в этом у паровоза который.
← →
jack128_ (2014-01-17 21:59) [19]Как это нет проф обсуждений? Во всех соц сетях есть группы по интересам, в том гугльплюс есть сообщества. И по Дельфи и по чему хочешь.
← →
Германн © (2014-01-17 22:10) [20]
> Вот говорят, что дельфи не умирает
Потому что все так считают (Пит)
← →
Jeer © (2014-01-17 23:17) [21]Фигня, все это - ваше программирование :)
Вело-клуб "Велокей" не умирает, а развивается.
Новички - адекватные ребята и девушки, с удовольствием погружаются
в новые для них испытания: взаимопомощь, честь, преодоление "препятствий" в рамках новых ощущений Мира: пространство, скорость, экстрим, уют, а, в итоге - достижение Цели для каждого.
← →
Novicer (2014-01-18 00:41) [22]Кому чего интересно в то и погружается :) я вот огнептиц пытаюсь хоть за хвост поймать, нифига не получается, но я не отстану пока хотя бы перышко из ее роскошного хвостика не отщипну ;) У меня много знакомых и друзей которые активно интересуются не только клубами и тусовками, но и техн.новинками, компами и даже программированием! ;) А вы говорите умирает, старичок Дельфи еще сам многих похоронит, пока концы отдаст, вернее реинкарнируется в РадСтудио :)
← →
Пит (2014-01-18 01:22) [23]
> Как это нет проф обсуждений? Во всех соц сетях есть группы
> по интересам, в том гугльплюс есть сообщества. И по Дельфи
> и по чему хочешь.
Жэка, я видел вконтактике. То, что видел по программингу - это на уровне дельфи за 24 часа. В гугле все по другому? Можно ссылку?
Stackoverflow да, грамотный ресурс, спорить не буду, народ зачастую серьезный сидит.
Но, собственно, к тебе приставать смысла нету, в осмыслении позиционирования и перспектив дельфи на рынке у нас с тобой одинаковое мнение... к сожалению (
← →
Пит (2014-01-18 01:26) [24]
> Фигня, все это - ваше программирование :)
ох договоришься ты когда-нибудь. Доеду я до тебя на своем merida tfs-300d и будешь мне рассказывать как за три дня проехать 600км )))
← →
Rouse_ © (2014-01-18 02:48) [25]«Человек жив, пока живет память о нем», – говорили древние.
Судя по периодичности создаваемых веток о умирании дельфи, она еще нас всех переживет :)
← →
MsGuns © (2014-01-18 03:06) [26]>Pavia © (17.01.14 19:43) [1]
>Между прочим новых лиц тут полно.
Не тешьте себя иллюзиями (с)
← →
jumping jack (2014-01-18 05:45) [27]говорят, ни одна технология после набора -> пика -> спада популярности назад к набору не возвращается (не считая локальных всплесков)
← →
параллелепипед (2014-01-18 06:16) [28]
> >Pavia © (17.01.14 19:43) [1]
> >Между прочим новых лиц тут полно.
>
> Не тешьте себя иллюзиями (с)
Согласен.
реинкарнаций, да действительно хватает.
Я тоже...
← →
jumping jack (2014-01-18 06:22) [29]в смысле "находятся на спаде популярности" Java и C++ тоже умирают
(если это кого-то успокоит)
← →
Несусвет (2014-01-18 06:50) [30]Вы не в теме.
FLASH говорят скоро исчезнет, но там появились шейдеры, вершинные буферы и поддержка видео-карты.
← →
Kerk © (2014-01-18 12:00) [31]
> Пит (18.01.14 01:22) [23]
> В гугле все по другому? Можно ссылку?
Ну вот хорошее сообщество
https://plus.google.com/communities/103113685381486591754
Одна из бросающихся в глаза причин, почему более современные средства коммуникаций выигрывают у старых форумов... в сообществах G+ люди вроде Марко Канту пишут о программировании, а на мастаках в каждой теме такие люди как Jeer пишут как они провели лето. В социальных сетях каждый может "выключить" надоевшего ему автора в полтора клика, поэтому они там не приживаются.
← →
Eraser © (2014-01-18 17:05) [32]
> Чем это можешь объяснить?
информации и сети стало намного больше, народ постепенно учится пользоваться поисковиками. это одна из причин.
ну а что касается данного форума, то он так и будет стагнировать пока не сделают техническую модернизацию и не прикрутят систему блогов, это как минимум. без этого форум интересен только тем, кто застал его 5-10 лет назад еще.
← →
ё (2014-01-18 23:30) [33]
> а на мастаках в каждой теме такие люди как Jeer пишут как
> они провели лето. В социальных сетях каждый может "выключить"
> надоевшего ему автора в полтора клика, поэтому они там не
> приживаются.
забанят же :-D
← →
MsGuns © (2014-01-19 02:00) [34]>Eraser © (18.01.14 17:05) [32]
>без этого форум интересен только тем, кто застал его 5-10 лет назад еще.
Увы и ах ! Не всем. Далеко не всем.
← →
имя (2014-01-19 02:04) [35]Удалено модератором
← →
Германн © (2014-01-19 03:04) [36]
> Одна из бросающихся в глаза причин, почему более современные
> средства коммуникаций выигрывают у старых форумов... в сообществах
> G+ люди вроде Марко Канту пишут о программировании, а на
> мастаках в каждой теме такие люди как Jeer пишут как они
> провели лето. В социальных сетях каждый может "выключить"
> надоевшего ему автора в полтора клика, поэтому они там не
> приживаются.
Так то кому как. Керку - керково, а нам своё, привычное.
← →
Eraser © (2014-01-19 03:19) [37]
> Германн © (19.01.14 03:04) [36]
> Керку - керково, а нам своё, привычное.
так потому "нас" и осталось 3 калеки (а скоро и их не будет), к которым я себя тоже причисляю. о чем и пишет топикстартер.
← →
Германн © (2014-01-19 04:16) [38]
> Eraser © (19.01.14 03:19) [37]
>
>
> > Германн © (19.01.14 03:04) [36]
>
>
> > Керку - керково, а нам своё, привычное.
>
> так потому "нас" и осталось 3 калеки (а скоро и их не будет),
> к которым я себя тоже причисляю. о чем и пишет топикстартер.
>
>
Дык кроме ДМ есть ещё туева хуча форумов по программированию. Хочешь - отвечай там. Будешь чувствовать себя "не калекой".
ДМ просто нечто особенное. Не влезающее ни в какие обычные рамки. И даже Керк это понимает, хоть возможно и не отдаёт себе в этом отчёт. :)
Я сей форум воспринимаю скорее как "курилку" в МИФИ в те годы, когда я там работал. Там (в курилке) разговаривали на весьма разные темы. Иногда научные, иногда нет. Иногда серьёзные, иногда нет. И т.д. и т.п. Главное это было общение "соратников".
← →
MonoLife © (2014-01-19 07:28) [39]квн уже не тот...
← →
картман © (2014-01-19 11:15) [40]
> Eraser © (19.01.14 03:19) [37]
>
>
> > Германн © (19.01.14 03:04) [36]
>
>
> > Керку - керково, а нам своё, привычное.
>
> так потому "нас" и осталось 3 калеки (а скоро и их не будет),
> к которым я себя тоже причисляю. о чем и пишет топикстартер.
>
В агонии Дельфи Jeer виноват?))
← →
robt5 (2014-01-19 12:29) [41]
> alexdn © (17.01.14 20:32) [9]
вагонку х64 едишн запуздырил уже?
← →
Kerk © (2014-01-19 13:24) [42]
> В агонии Дельфи Jeer виноват?))
Мы ж про форум
← →
картман © (2014-01-19 13:52) [43]
> Kerk © (19.01.14 13:24) [42]
>
>
> > В агонии Дельфи Jeer виноват?))
>
> Мы ж про форум
а топикстартер - про дельфи!
← →
ухты (2014-01-19 13:57) [44]еще несколько лет назад казалось что делфи уже не поднимется, сейчас картина несколько изменилась, правда много, очень много потеряно..
и главное это то, чтобы не профукали то что начали сейчас, а опыт к сожалению есть :)
← →
clickmaker © (2014-01-19 14:04) [45]может, дельфи и умирает мучительно в агонии, но программы написанные еще аж на пятерке до сих пор живут и некоторые даже работают
← →
картман © (2014-01-19 15:00) [46]Млин, да что бы им не работать? Все это умирание есть чистый маркетинг и ничего более.
← →
clickmaker © (2014-01-19 15:13) [47]> Все это умирание есть чистый маркетинг и ничего более
Типа как "Пугачева уходит со сцены и вообще больше не поет", "Кобзон дал свой прощальный тур"? ))
← →
картман © (2014-01-19 15:42) [48]
> clickmaker © (19.01.14 15:13) [47]
нет))
вот С# в последние годы набрал популярность, в то время, когда популярность дельфи падала, а какие у него есть преимущества?
← →
clickmaker © (2014-01-19 15:48) [49]> какие у него есть преимущества?
это может стать началом очередного холивора )
← →
Jeer © (2014-01-19 16:23) [50]>> В агонии Дельфи Jeer виноват?))
>Kerk
>Мы ж про форум
Раз так, тогда тем более про Delphi упоминать даже не буду, а то еще и Ембаркадеро или кто там им владеет, развалится. :)
← →
Плохиш © (2014-01-19 16:43) [51]
> вот С# в последние годы набрал популярность, в то время,
> когда популярность дельфи падала, а какие у него есть преимущества?
>
В языке может и нет больших, хотя те же дженерики органически вписаны. А в IDE есть, тот же LINQ, к примеру. Да и для популизации ms много делает, те же express версии.
← →
картман © (2014-01-19 16:45) [52]
> Да и для популизации ms много делает
о чем и речь
← →
antonn © (2014-01-19 17:12) [53]
> А в IDE есть, тот же LINQ, к примеру.
я на втором дотнете пишу, и без линка видно что говнокодить проще на шарпе :)
← →
Kerk © (2014-01-19 17:28) [54]Есть - назовем это так - предчувствия, что очень скоро мы сможем увидеть сильно урезанную, но бесплатную версию Delphi. Согласно этим предчувствиям, нас ждут очень серьезные перемены.
← →
antonn © (2014-01-19 17:43) [55]
> Согласно этим предчувствиям, нас ждут очень серьезные перемены.
какие?
← →
Eraser © (2014-01-19 18:19) [56]эх, не плохо бы, если бы для FMX они наняли нормального архитектора. на сколько было бы меньше проблем, если бы была возможность гибко подменять классы и перекрывать все методы самого ядра FMX. хороший пример - Indy.
сейчас получается что они упороли кучу косяков в коде, а поправить что-то самому крайне проблематично.
← →
Kerk © (2014-01-19 18:27) [57]
> antonn © (19.01.14 17:43) [55]
Менее туманно я эти предчувствия озвучить не могу :(
← →
clickmaker © (2014-01-19 18:43) [58]да куда уж менее туманно...
← →
antonn © (2014-01-19 19:09) [59]
> Kerk © (19.01.14 18:27) [57]
>
>
> > antonn © (19.01.14 17:43) [55]
>
> Менее туманно я эти предчувствия озвучить не могу :(
если речь о том "что будет с нами", то мне кажется все тут, кто не застрял в прошлом, уже освоил более-менее современные РАД и другие языки, потому проблем с работой быть не должно. А кроме как в этом направлении ждать плохих перемен вроде бы незачем
← →
Kerk © (2014-01-19 19:29) [60]
> antonn © (19.01.14 19:09) [59]
Да я не "про нас". Мы-то не пропадем. Ну по крайней мере часть из нас.
А вот Delphi сейчас в сложной ситуации. Сообщество очень сегментировано.
Я наверно сейчас не очень популярную вещь скажу...
Есть очень большая группа тех, кто застрял в мире Delphi 7 (условно). Они всю эту движуху вокруг FMX и кроссплатформенности воспринимают как клоунаду. Ну вот сидит человек на заводе, автоматизирует АСУ. Нафига ему все эти айфоны? Если думать о Delphi, подразумевая исключительно эту категорию программистов (а многие так и делают, их ведь много), то Delphi давно и безнадежно мертвая штука.
Есть менее многочисленная группа тех, кому интересна кроссплатформенность и кто очень хочет свой Delphi-опыт в связи с этим применить. Этих людей меньше, чем первых, но они есть и их невозможно игнорировать. И если думать о Delphi сквозь призму этих людей, то Delphi - это очень МОЛОДОЕ и динамично развивающееся средство разработки. Да, Delphi тащит за собой кучу металлолома вроде VCL, но за это "спасибо" предыдущей группе ретроградов.
Мое мнение - ретроградов будут использовать как дрова, сжигая в топке нового Delphi. Невозможно вечно поддерживать жизнь "в мире Delphi 7", но фактом его существования грех не воспользоваться.
← →
Kerk © (2014-01-19 19:31) [61]
> antonn © (19.01.14 19:09) [59]
> А кроме как в этом направлении ждать плохих перемен вроде
> бы незачем
Плохих предчувствий у меня как раз нет. По крайней мере краткосрочно.
← →
картман © (2014-01-19 20:25) [62]
> Мое мнение - ретроградов будут использовать как дрова, сжигая
> в топке нового Delphi.
что бы это значило...
← →
Юрий Зотов © (2014-01-19 20:28) [63]> Kerk © (19.01.14 19:29) [60]
Сколько, по твоим оценкам, нужно времени, чтобы с D7 перейти на XE5?
← →
Kerk © (2014-01-19 20:44) [64]
> Юрий Зотов © (19.01.14 20:28) [63]
>
> > Kerk © (19.01.14 19:29) [60]
>
> Сколько, по твоим оценкам, нужно времени, чтобы с D7 перейти на XE5?
Это ведь целиком от проекта зависит.
У меня был опыт участия в переносе небольшого (но и не очень маленького) проекта с D2006 на XE2. Думаю, это сопоставимо с D7->XE5. Обобщая и суммируя, можно сказать, что один выделенный человек с небольшими перерывами занимался этим переносом примерно полгода.
Другой вопрос: а нафига? Нам позарез нужен был юникод и мы держали в уме возможность в будущем сделать 64битную версию. Но многим проектам этот юникод и 64 бита совсем не нужны. Про всякие языковые приятности вроде дженериков я даже не говорю, потому что объяснить менеджменту что такое дженерики и как они окупят затраты на обновление Delphi бывает не так-то просто.
"Мир Delphi 7" не просто так возник. Он возник потому, что многих людей он вполне устраивает.
← →
Юрий Зотов © (2014-01-19 20:59) [65]> Kerk © (19.01.14 20:44) [64]
Извини, неточно сформулировал вопрос. Я имел в виду не перевод проекта, а человека - сколько ему нужно времени, чтобы, зная D7, начать уверенно работать на XE5 ?
Сюда входят освоение IDE, новых фич синтаксиса, часто используемых новых классов и т.п.
← →
Юрий Зотов © (2014-01-19 21:00) [66]Имеется в виду Win32/64, конечно. Не андроид.
← →
clickmaker © (2014-01-19 21:08) [67]> сколько ему нужно времени, чтобы, зная D7, начать уверенно
> работать на XE5 ?
часа два. Из них час на установку и успешный запуск.
← →
Kerk © (2014-01-19 21:13) [68]
> Юрий Зотов © (19.01.14 20:59) [65]
Тогда да, два часа - вполне реальная оценка по-моему. Там есть конечно различия, но вряд ли они вызовут затруднения у адекватного человека.
← →
Германн © (2014-01-19 21:23) [69]
> Eraser © (19.01.14 18:19) [56]
>
> эх, не плохо бы, если бы для FMX они наняли нормального
> архитектора. на сколько было бы меньше проблем, если бы
> была возможность гибко подменять классы и перекрывать все
> методы самого ядра FMX. хороший пример - Indy.
> сейчас получается что они упороли кучу косяков в коде, а
> поправить что-то самому крайне проблематично.
А кто-то (не будем показывать пальцем кто) говорил что Инди на ФМХ хорошо работает.
← →
Юрий Зотов © (2014-01-19 21:29) [70]
> clickmaker © (19.01.14 21:08) [67]
> Kerk © (19.01.14 21:13) [68]
Тогда ишшо поживем. Как выяснилось, между миром D7 и миром XE пропасти нет. Да и топка не такая уж страшная.
:o)
← →
vuk © (2014-01-19 21:56) [71]to Kerk © (19.01.14 19:29) [60]:
> Да, Delphi тащит за собой кучу металлолома вроде VCL
Я, канешна, дико извиняюсь, но этот "металлолом" - это то, на чем реализованы существующие проекты. Они работают и их надо поддерживать. И если в Embarcadero разделяют такое отношение к VCL именно как к металлолому, то Delphi действительно сдыхает.
← →
Kerk © (2014-01-19 22:18) [72]
> vuk © (19.01.14 21:56) [71]
VCL - это мастадонт... гигант, которому Delphi многим обязана. Но очень трудно уже придумать что-то новое, ради чего разработчики VCL-проектов будут покупать новые версии Delphi. Для их поддержки этих проектов и существующих версий Delphi вполне достаточно.
Вот сейчас допустим обновятся те, кто еще остался в доюникодной эре и дальше что?
Ну вот сам подумай. Допустим, у тебя есть Delphi XE5. Что нужно добавить в VCL, чтобы ты обязательно купил Delphi XE6?
А вот в FireMonkey возможностей для развития еще невероятное множество.
Дотнет как-то ведь пережил уход WinForms с главных ролей. Почему бы и Delphi не пережить нечто подобное? В какой-то момент стоит перестать цепляться за прошлое и посмотреть вперед.
← →
Jeer © (2014-01-19 22:34) [73]>В какой-то момент стоит перестать цепляться за прошлое и посмотреть вперед.
Не, мне регулярно интересна молодежь, почти уже как потребность в сексе.
Какого.. вы считаете, что разработка/поддержка/использование давно опробированных и работающих продуктов типа D7, тем более пока поддерживаемых Win-Осями, ретроградством?
И, почему, вы считаете, что у "ретроградов" только D7 на уме или даже продукты Delphi-мейстрима?
Надо - легко уходим в другие технологии.
С другой стороны, да - лично я, "клоунадой" не занимался и не буду - проще клоунов нанять для таких же Заказчиком-клоунов.
Толку от этих йоб-Падов - чуть.
← →
antonn © (2014-01-19 22:39) [74]
> Есть очень большая группа тех, кто застрял в мире Delphi
> 7 (условно). Они всю эту движуху вокруг FMX и кроссплатформенности
> воспринимают как клоунаду.
я, честно говоря, кроссплатформенность тут тоже воспринимаю как рюшечку, и предпочту тот ЯП что лучшим образом подходит под решение задачи. Конечно в этом случае нужно владеть еще одним ЯП+студия (или не одним, как повезет) и отсутствием ограничений (корпоративный стандарт, например).
← →
vuk © (2014-01-19 22:59) [75]to Kerk © (19.01.14 22:18) [72]:
> Ну вот сам подумай. Допустим, у тебя есть Delphi XE5. Что
> нужно добавить в VCL, чтобы ты обязательно купил Delphi
> XE6?
>
> А вот в FireMonkey возможностей для развития еще невероятное
> множество.
Тут такое дело. Большинство пользователей Delphi, в силу сложившейся ситуации, занимается именно тем, для чего VCL вполне годится. И сколько бы новых фич ни появилось в FireMonkey, им с этого не холодно и не жарко - все их текущие проекты один хрен не на этом и перенести их туда не будет ни возможности, ни смысла. Те, кому изначально были нужны те мобильные платформы, на которые Delphi сейчас активно лезет, вряд ли начнут работать с Delphi, т.к. для этих платформ есть родные средства разработки, более для них естественные. Так что единственная логичная аудитория, которой всё это новое может понадобиться - текущие пользователи, у которых есть некая надобность к существующим проектам подключать мобильные устройства. Много таких? Не уверен.
> В какой-то момент стоит перестать цепляться за прошлое и
> посмотреть вперед.
Я понимаю Embarcadero, им хочется попытаться урвать кусочек от растущего рынка. Тут главное, чтобы не получлось так, что и нового не отхватят и старое растеряют.
← →
Плохиш © (2014-01-19 23:26) [76]
> antonn © (19.01.14 17:12) [53]
>
>
> > А в IDE есть, тот же LINQ, к примеру.
>
> я на втором дотнете пишу, и без линка видно что говнокодить
> проще на шарпе :)
Наличие говнокодеров от языков не зависит.
← →
Плохиш © (2014-01-19 23:27) [77]
> предчувствия, что очень скоро мы сможем увидеть сильно урезанную,
> но бесплатную версию Delphi.
Волшебные слова. Один раз они уже по этим граблям топтались :-(
← →
Eraser © (2014-01-19 23:50) [78]
> Германн © (19.01.14 21:23) [69]
Indy на FMX хорошо работает! где я писал обратное?
← →
Германн © (2014-01-20 00:05) [79]
> Eraser © (19.01.14 23:50) [78]
Значит я неправильно понял.
← →
Eraser © (2014-01-20 00:14) [80]
> Kerk © (19.01.14 19:29) [60]
> Есть менее многочисленная группа тех, кому интересна кроссплатформенность
> и кто очень хочет свой Delphi-опыт в связи с этим применить.
> Этих людей меньше, чем первых, но они есть и их невозможно
> игнорировать. И если думать о Delphi сквозь призму этих
> людей, то Delphi - это очень МОЛОДОЕ и динамично развивающееся
> средство разработки. Да, Delphi тащит за собой кучу металлолома
> вроде VCL, но за это "спасибо" предыдущей группе ретроградов.
>
плюсую.
с FMX столкнулся на практике, уже есть готовые, хоть и примитивные, по сравнению с конкурентами версии для андроид и ios.
не сочтите за рекламу (это все равно бесплатно)
https://itunes.apple.com/us/app/remote-utilities/id793320970?l=ru&ls=1&mt=8
https://play.google.com/store/apps/details?id=com.remoteutilities.mviewer
впечатления от разработки (особенно в части андроида) именно такие - много т.н. "детских болезней". года через 2 FMX будет отличный инструмент, которому не будет аналогов по качеству размаху. т.к. разработкой занимаются все таки не стартапщики-любители, а компания, которая делает инструмент для разработки не один десяток лет.
← →
jumping jack (2014-01-20 00:36) [81]ничего себе, тему разогнали!
однажды я размечтался о том, как бы всё могло сложиться, если бы Борланд отдал Дельфи в оупенсорс на пару с Интербейзом в 2000-м году...
а неплохо могло бы получиться: заниматься компилятором, может быть, и мало кто захотел бы, а вот VCL бы наверняка довели бы до кроссплатформенности, как сейчас Lazarus LCL - и это могло бы стать единой (безальтернативной) платформой для дельфи-компонентописателей и реальным конкурентом дотнету
(FPC, будучи совместимым с Дельфи, обеспечивал бы компиляцию того же самого кода под остальное железо)
а фрагментация единого на Classic VCL / CLX / LCL / FMX - хорошего мало дала
← →
Kerk © (2014-01-20 00:53) [82]
> vuk © (19.01.14 22:59) [75]
> Те, кому изначально были нужны те мобильные платформы, на
> которые Delphi сейчас активно лезет, вряд ли начнут работать
> с Delphi, т.к. для этих платформ есть родные средства разработки,
> более для них естественные.
Время покажет. На самом деле количество появившихся в последнее время кроссплатформенных средств разработки для мобильных платформ наталкивает на мысль, что спрос на такие решения есть и немалый. Кто-то готов переплачивать за естественность, кто-то - нет. Ты сам на пальцах прикинь разницу в стоимости разработки одного проекта для разных платформ и отдельного проекта для каждой из платформ. А ведь нужно не только разрабатывать, но и сопровождать.
← →
Kerk © (2014-01-20 00:55) [83]
> vuk © (19.01.14 22:59) [75]
> Большинство пользователей Delphi, в силу сложившейся ситуации,
> занимается именно тем, для чего VCL вполне годится. И сколько
> бы новых фич ни появилось в FireMonkey, им с этого не холодно
> и не жарко - все их текущие проекты один хрен не на этом
> и перенести их туда не будет ни возможности, ни смысла.
Это все замечательно, но Embarcadero, как мне кажется, не собирается самораспускаться и поэтому ищет какие-то пути для развития Delphi, оставив позади те технологии на развитие которых спроса больше нет.
← →
jumping jack (2014-01-20 01:19) [84]Kerk> оставив позади те технологии на развитие которых спроса больше нет.
я бы сказал, что спрос есть на кроссплатформенный User Interface, и VCL могло бы развитсья в эту сторону (как LCL), но не стало
то есть попросту предложения адекватного (именно со стороны разработчиков VCL) нет, а спрос достаточно гибок, чтобы удовлетворится заменой (FMX, кто не дождался - Qt, LCL, html/server scripting)
← →
Kerk © (2014-01-20 01:23) [85]Я, честно говоря, слабо себе представляю развитие VCL в сторону кроссплатформенности без потери совместимости с предыдущими версиями. VCL, на мой скромный взгляд, намертво на Windows завязана.
← →
jumping jack (2014-01-20 01:36) [86]Lazarus LCL - те же компоненты, практически тот же набор свойств и методов
конечно, совместимость не 100%, ну так чудес не бывает, переход на юникод тоже не "раз плюнуть"
гораздо лучше, когда выбор между модернизированным старым (с максимальной обратной совместимостью) и радикально новым (типа "отряхнем её пыль с наших ног") позволено сделать покупателю/пользователю, т.е. ему предоставлены оба варианта (имхо, большинство всегда выберет первый, так что производитель может смело отдать второй вариант на откуп технологическим партнерам)
← →
vuk © (2014-01-20 01:37) [87]to Kerk © (20.01.14 00:53) [82]:
> Ты сам на пальцах прикинь разницу в стоимости разработки
> одного проекта для разных платформ и отдельного проекта
> для каждой из платформ.
Вот именно об этом я и говорю. В существующих условиях, если не с нуля начинать, будет именно что отдельный проект для каждой платформы. По причине непереносимости старого.
> А ведь нужно не только разрабатывать, но и сопровождать.
Угу. Все то, что написано на VCL тоже, как ни странно, надо и сопровождать и развивать.
> Это все замечательно, но Embarcadero, как мне кажется, не
> собирается самораспускаться и поэтому ищет какие-то пути
> для развития Delphi, оставив позади те технологии на развитие
> которых спроса больше нет.
Это не "нет спроса". Спрос на приложения и средства их разработки никуда не делся. Это, на мой взгляд некий процесс из серии:
1 берем (или придумываем) некую технологию, начинаем её развивать
2 кругом непаханное поле, работы - дофига, называем все это прогрессом
3 прикручиваем к технологии кучу наворотов
4 долго ловим баги и прикручиваем новые фичи
5 понимаем, что доприкручивались до такого, что идеи кончились, прикручивать дальше уже трудно, а деньги начинают кончаются
6 откладываем в сторону и объявляем устаревшим, а тех, кто с этим имел (не)счастье работать - ретроградами
7 goto 1
:)
← →
Kerk © (2014-01-20 01:51) [88]
> vuk © (20.01.14 01:37) [87]
>
> to Kerk © (20.01.14 00:53) [82]:
>
> > Ты сам на пальцах прикинь разницу в стоимости разработки
> > одного проекта для разных платформ и отдельного проекта
> > для каждой из платформ.
>
> Вот именно об этом я и говорю. В существующих условиях,
> если не с нуля начинать, будет именно что отдельный проект
> для каждой платформы. По причине непереносимости старого.
Я отвечал на реплику: "для этих платформ есть родные средства разработки, более для них естественные". Причем тут "старое" вообще?
> Угу. Все то, что написано на VCL тоже, как ни странно, надо
> и сопровождать и развивать.
Я говорю, что два проекта (iOS + Android) сопровождать дороже, чем один кроссплатформенный. Причем тут вообще VCL?
Я не понимаю, что именно ты мне хочешь сказать. VCL никуда не девается, ты все еще можешь пользоваться любой понравившейся тебе версией Delphi. Но на вопрос "что нужно добавить в VCL, чтобы ты обязательно купил Delphi XE6" ты не ответил. Получается, я прав и в твоем лице спрос на развитие VCL отсутствует.
← →
Плохиш © (2014-01-20 02:00) [89]
> Kerk © (20.01.14 01:51) [88]
Кстати, спрошу у тебя.
В самом начале скачал xe5 и там, вроде, FireMonkey проекты не были разделены на десктоп и мобильные и в одном проекте было переключение между desktop, ios и android. А сейчас скачал и там два типа проектов, одельно для десктопа и отдельно для мобильных. Их действительно разделили или меня память подводит?
← →
vuk © (2014-01-20 02:01) [90]to Kerk © (20.01.14 01:51) [88]:
> Но на вопрос "что нужно добавить в VCL, чтобы ты обязательно
> купил Delphi XE6" ты не ответил.
Чего бы я там хотел, там никогда не появится. Потому, что это совсем другая реализация дизайнера и вообще не совсем уверен, что нормально реализуемо. Например, избавление от DFM и генерация вместо этого кода инициализации компонентов было бы просто счастьем. :)
← →
Плохиш © (2014-01-20 02:02) [91]
> Но на вопрос "что нужно добавить в VCL, чтобы ты обязательно
> купил Delphi XE6"
По-моему, совершенно не сильно важно, что добавят в VCL, важно, какие дополнительные средства добавят для облегчения разработки и технологии.
← →
jumping jack (2014-01-20 02:22) [92]> "что нужно добавить в VCL, чтобы ты обязательно купил Delphi XE6"
дык поддержку компиляции под Linux, MacOs (Android, iOs - по
возможности), 100% обратной совместимости не требую, хотя бы 99% :)
фантастика, говорите?
ну так вот и я об этом
← →
Eraser © (2014-01-20 02:22) [93]
> Kerk © (20.01.14 01:23) [85]
> Я, честно говоря, слабо себе представляю развитие VCL в
> сторону кроссплатформенности без потери совместимости с
> предыдущими версиями. VCL, на мой скромный взгляд, намертво
> на Windows завязана.
на какой-то конференции задавали подобный вопрос. ответ был такой, что всерьез рассматривалась разработка некой, если не подводит память, VCL+, даже были наработки, потом решили, что лучше отдельно сделать.
← →
jumping jack (2014-01-20 02:38) [94]Kerk> VCL, на мой скромный взгляд, намертво на Windows завязана.
реализация VCL на Windows завязана. ну так еще бы - это же реализация под Windows!
объектный интерфейс (свойства и методы), тем не менее, считать к чему-то привязанным вряд ли можно, разве что реализовать его для других платформ без изменений немного сложнее, чем было бы в случае, если бы он сразу проектировался с такой целью
но это чисто технические трудности и всегда есть компромисс (между трудоемкостью и количеством допущенных отклонений от "референсной реализации")
← →
имя (2014-01-20 03:42) [95]Удалено модератором
← →
имя (2014-01-20 03:44) [96]Удалено модератором
← →
antonn © (2014-01-20 08:07) [97]
> Плохиш © (19.01.14 23:26) [76]
>
>
> > antonn © (19.01.14 17:12) [53]
> >
> >
> > > А в IDE есть, тот же LINQ, к примеру.
> >
> > я на втором дотнете пишу, и без линка видно что говнокодить
> > проще на шарпе :)
>
> Наличие говнокодеров от языков не зависит.
наличие - нет, процент - да, в шарпе с этим проще, никаких free, указателей, послабления в межпоточном обмене, можно даже со строками не заморачиваться - все равно тормозит и много кушает памяти :)
а уж со всякими линками и прочими финтифлюшками студии позволяющие одним пальцем сгенерить стену текста - и подавно
← →
Inovet © (2014-01-20 09:18) [98]> [90] vuk © (20.01.14 02:01)
> Например, избавление от DFM и генерация вместо этого кода
> инициализации компонентов
Т.е. вместо ресурсов код. Кошерно ли так? Всё равно какой-то части в ресурсах более подходящее место.
← →
vuk © (2014-01-20 09:52) [99]to Inovet © (20.01.14 09:18) [98]
> Т.е. вместо ресурсов код. Кошерно ли так? Всё равно какой-
> то части в ресурсах более подходящее место.
Кошерно. В ресурсах надо держать строки и картинки, а для остального наличие dfm еще со времени появления наследования форм, а в особенности - с появлением фреймов, создает только кучу проблем. Вот только проблемы эти понятны, но не решаются. И не будут, я так думаю.
← →
ТимоховД (2014-01-20 09:58) [100]У меня вот XE3 есть. Никак поставить не могу. Хочу Андроид, и АйФон.
Но АСУ... и мир Дельфи 7 держит на месте.
Мое имхо, дельфи не умрет до тех пор, пока будут десктопные приложения. Когда превалировать будут онлайн приложения, тут да... дельфи не силен.
ЗЫ. Про старичков в АСУ не говорю - они будут всегда.
← →
ТимоховД (2014-01-20 09:58) [101]У меня вот XE3 есть. Никак поставить не могу. Хочу Андроид, и АйФон.
Но АСУ... и мир Дельфи 7 держит на месте.
Мое имхо, дельфи не умрет до тех пор, пока будут десктопные приложения. Когда превалировать будут онлайн приложения, тут да... дельфи не силен.
ЗЫ. Про старичков в АСУ не говорю - они будут всегда.
← →
clickmaker © (2014-01-20 10:09) [102]> Про старичков в АСУ не говорю - они будут всегда
Которые кодят в госучреждениях за элт-мониторами, сидя на коробках из-под них же ))
← →
Kerk © (2014-01-20 10:20) [103]
> jumping jack (20.01.14 02:38) [94]
>
> Kerk> VCL, на мой скромный взгляд, намертво на Windows завязана.
>
> реализация VCL на Windows завязана. ну так еще бы - это
> же реализация под Windows!
>
> объектный интерфейс (свойства и методы), тем не менее, считать
> к чему-то привязанным вряд ли можно, разве что реализовать
> его для других платформ без изменений немного сложнее, чем
> было бы в случае, если бы он сразу проектировался с такой
> целью
>
> но это чисто технические трудности и всегда есть компромисс
> (между трудоемкостью и количеством допущенных отклонений
> от "референсной реализации")
В теории-то все красиво, но на практике почему-то нет ни одной популярной визуальной библиотеки для какого-либо языка, которая бы реализовала подобное.
Про LCL не надо, он вместе со своим Lazarus"ом - жалкое подобие D7. Можно какие-то более промышленные примеры доказывающие возможность того, о чем ты говоришь?
Это абстрактно говорить легко, а на практике оказывается, то в разных ОС контролы ведут себя по-разному, имеют разные свойства и разные методы.
> Плохиш © (20.01.14 02:00) [89]
> В самом начале скачал xe5 и там, вроде, FireMonkey проекты
> не были разделены на десктоп и мобильные и в одном проекте
> было переключение между desktop, ios и android. А сейчас
> скачал и там два типа проектов, одельно для десктопа и отдельно
> для мобильных. Их действительно разделили или меня память
> подводит?
Не-не, так и было с самого начала.
← →
Kerk © (2014-01-20 10:23) [104]
> Можно какие-то более промышленные примеры доказывающие возможность
> того, о чем ты говоришь?
Уточню. VCL - это набор оберток над элементами управления ОС. В этом и ее сила, и ее слабость. А всякие FMX/Qt - это совсем другое. Так что как ответом на мой вопрос считаться не могут :)
← →
Kerk © (2014-01-20 10:24) [105]Удалено модератором
← →
vuk © (2014-01-20 10:31) [106]Удалено модератором
← →
Kerk © (2014-01-20 10:37) [107]Удалено модератором
← →
Германн © (2014-01-20 10:44) [108]
> VCL - это в первую очередь TForm, TButton, TEdit, TListBox,
> TOpenDialog и так далее.
И до сих пор нет нормального компонента/функции по выбору директории. Ну типа 20 лет без него прожили так и дальше не умрете.
← →
vuk © (2014-01-20 10:47) [109]Удалено модератором
← →
Kerk © (2014-01-20 10:59) [110]Удалено модератором
← →
vuk © (2014-01-20 11:04) [111]Удалено модератором
← →
Kerk © (2014-01-20 11:09) [112]Удалено модератором
← →
Kerk © (2014-01-20 11:09) [113]Возвращаясь к вопросу о умирании форумов.
Наглядный пример можно пронаблюдать на последних страницах. Вот я высказываю свою точку зрения (имею же я право на это?). Но вдруг выскакивает пациент и начинает с кучкой шуток/прибауток и смайликов пытаться эту точку зрения опровергнуть. Причем чего сам пациент хочет совсем не понятно, для него спор - это самоцель.
При нормально строящемся разговоре он бы высказал свою точку зрения в противовес моей и мы спокойно бы поговорили, возможно остановившись на чем-то среднем. Но у пациента озвученной своей точки зрения нет, у него другие цели.
Социальные сети позволяют фильтровать таких борцунов, форумы - нет.
← →
vuk © (2014-01-20 11:17) [114]to Kerk © (20.01.14 11:09) [112]:
> Ты чего сказать-то хотел? Что VCL легко портировать под
> мак и андроид?
Нет, я этого сказать не хотел. То, что VCL в основном заточена под виндовые контролы (не элементы управления ОС) оно понятно, хотя, в свое время были благополучно похороненные вариации на тему и под дотнет и под линукс.
to Kerk © (20.01.14 11:09) [113]
> Но вдруг выскакивает пациент
В дурдоме же оно как, кто первый халат надел, тот и доктор.
← →
Kerk © (2014-01-20 11:24) [115]
> vuk © (20.01.14 11:17) [114]
> То, что VCL в основном заточена под виндовые контролы (не
> элементы управления ОС) оно понятно
Ну так если понятно, то чего тогда столько словоблудия со смайликами тут развел?
Для полноты счастья тебе осталось заглянуть в словарь и узнать, что "control" переводится именно как "элемент управления".
← →
jumping jack (2014-01-20 11:30) [116]Kerk ©> Можно какие-то более промышленные примеры доказывающие возможность того, о чем ты говоришь?
Непонятно, как "промышленные" примеры могут что-то доказать лучше "непромышленных", ну да ладно.
Доказать техническую возможность? Она, я считаю, очевидна: всё, что можно сделать в одной системе, можно хотя бы эмулировать в другой, если она имеет те же принципиальные возможности. WINE - пример тут совсем неудачный, но раз уж вспомнился - напишу.
Доказать коммерческую оправданность этого? Вот с этим сложности, раз уж сам Эмбаркадеро решил иначе. Я просто размышляю о том, какие еще тут были возможны варианты. Qt не подходит, но вот возьмем компоненты CLX (на основе Qt): похожи они на VCL? да практически один к одному! говорят, в некоторых проектах достаточно добавить "Q" к названиям модулей и сразу же (удачно) перекомпилировать! (это достаточно доказывает возможность?) Можно было его развить? Можно, но, очевидно, вариант с VGScene показался эмбе проще и беспроблемнее. А жаль! CLX был гораздо ближе к VCL, почти то, что нужно (за исключением ненативности Qt для Дельфи).
← →
vuk © (2014-01-20 11:30) [117]to Kerk © (20.01.14 11:24) [115]:
> Для полноты счастья тебе осталось заглянуть в словарь и
> узнать, что "control" переводится именно как "элемент управления".
>
Для полноты счастья, рекомендую уяснить, что не все, что элемент управления, реализовано ОС.
← →
имя (2014-01-20 11:31) [118]Удалено модератором
← →
Kerk © (2014-01-20 11:41) [119]Удалено модератором
← →
jumping jack (2014-01-20 11:41) [120]Kerk ©> Уточню. VCL - это набор оберток над элементами управления ОС
А CLX - набор оберток над набором оберток для разных ОС (универсальным)
но очень уж похож на VCL, ну точь-в-точь
А LCL - уже сразу универсальный набор оберток
и тоже очень-очень похож на VCL
может быть, суть "спора" в том, что ты под VCL понимаешь именно существующую реализацию VCL и, видимо, будешь продолжать настаивать на этом "определении"
а я пытаюсь объяснить, что под VCL тут понимаю именно объектный интерфейс этого фреймворка и принципиальную возможность других альтернативных его реализаций
в этом смысле CLX = VCL (т.к. их интерфейсы почти 100% совместимы)
← →
Kerk © (2014-01-20 11:59) [121]
> jumping jack (20.01.14 11:41) [120]
Наверно ты прав.
Вот в чем слабость FMX? Контролы не настоящие. Они могут как угодно точно пытаться копировать настоящие контролы ОС, но никогда не получится сделать это на 100% для всех платформ сразу.
Так же и с Qt. Qt - это хорошо, но приложение использующее Qt ведь все равно отличается от нативного. Я, пожалуй, на глаз смогу отличить.
И что касается VCL... ты называешь это реализацией, которую можно подменить, но мне кажется, что сила VCL как раз в том, что внутри там не какая-то имитация, а настоящая ОС. Тут пытаются приводить в пример cxGrid, но даже внутри этих гридов все построено на виндовых оконных сообщениях, виндовых функциях рисования и т.п. То есть и сторонние компоненты пришлось бы полностью переделывать. И не факт, что это было бы проще, чем написать с нуля под FMX.
То есть по-моему двинуть VCL в сторону кроссплатформенности означало бы отказаться от определенных преимуществ ей присущих с рождения. Может быть поэтому и решили оставить VCL в покое и для кроссплатформенности сделали новую библиотеку.
← →
DVM © (2014-01-20 12:04) [122]
> Kerk © (20.01.14 11:59) [121]
> Так же и с Qt. Qt - это хорошо, но приложение использующее
> Qt ведь все равно отличается от нативного. Я, пожалуй, на
> глаз смогу отличить.
Qt может использовать системную нативную отрисовку, такие не отличишь.
← →
DevilDevil © (2014-01-20 12:11) [123]Я пока не понял об чём спор
Но
> Так же и с Qt. Qt - это хорошо, но приложение использующее
> Qt ведь все равно отличается от нативного. Я, пожалуй, на глаз смогу отличить.
Разве что не-API-отрисованное окно перерисовывается нормально и не мерцает. Это плюс
← →
antonn © (2014-01-20 12:17) [124]
>
> И до сих пор нет нормального компонента/функции по выбору
> директории. Ну типа 20 лет без него прожили так и дальше
> не умрете.
http://desksoft.ru/index.php?downloads=files&id=9
или скатываемся к тому, что я давно наблюдаю в кругах шарпа - люди не ищут возможность реализовывать, а ищут готовую функцию/класс с помощью которой все сделано. 100 вещей - найти 100 классов.
← →
DVM © (2014-01-20 12:19) [125]
> DevilDevil © (20.01.14 12:11) [123]
> Разве что не-API-отрисованное окно перерисовывается нормально
> и не мерцает. Это плюс
API окно тоже не мерцает. Это в VCL так сделано.
← →
Kerk © (2014-01-20 12:28) [126]Те Qt-приложения, что я использовал, отличаются от нативных. Но может быть я не прав и/или мои сведения просто устарели.
Но разговор куда-то в дебри зашел. Я бы остановился на своем [60] и хватит. Теоретические перспективы кроссплатформенного VCL обсудить можно, но вот не сделали и его и все тут. А сделали FMX.
← →
DevilDevil © (2014-01-20 12:37) [127]> API окно тоже не мерцает. Это в VCL так сделано.
зачем ?
← →
DVM © (2014-01-20 12:39) [128]
> А сделали FMX.
По FMX надо в срочном порядке выпускать литературу. Ни одной книги ведь. Справка не в счет.
← →
Плохиш © (2014-01-20 12:40) [129]Ветка скатывается, как всегда :-(
Предлагаю обсудить, почему мелкий софт при расширении области применения своих средств разработки от десктопа, положил большой болт на winforms и создал wpf? Тот же мульти-тач поддерживается только в wpf.
← →
DVM © (2014-01-20 12:41) [130]
> DevilDevil © (20.01.14 12:37) [127]
> зачем ?
Так получилось. Все мерцание из-за стирания фона где надо и где не надо бы.
← →
DVM © (2014-01-20 12:42) [131]
> Плохиш © (20.01.14 12:40) [129]
> Предлагаю обсудить, почему мелкий софт при расширении области
> применения своих средств разработки от десктопа, положил
> большой болт на winforms и создал wpf?
Он уже и на wpf положил.
← →
Inovet © (2014-01-20 12:46) [132]> [131] DVM © (20.01.14 12:42)
> Он уже и на wpf положил.
На что он только не положил.
← →
clickmaker © (2014-01-20 12:49) [133]> По FMX надо в срочном порядке выпускать литературу. Ни одной
> книги ведь
если каждый из форумчан, имевший счастье сталкиваться с fmx, напишет по посту-другому, на брошюрку наберется)
← →
Плохиш © (2014-01-20 13:13) [134]Основы использования и программирования может описать только разработчик, если захочет популизовать продукт.
А в постах, что описовать? Для них вопросы нужны. Вот последнее у меня был вопрос по связи грида с источником данных и форматирования столбцов в гриде. Ничего, за полчаса с попить чайку и егойной матерью разобрался :-)
Кстати, документации и описаний на сайте производителя достаточно. Все возникающие неописанные тонкости ищутся в гугле довольно быстро, если знаешь что ищешь и выставишь сразу правильный язык общения на этом форуме (очень не рекомендую выставлять всякие аглицкие и немецкие, будете по кругу читать описание производителя) :-)
← →
Inovet © (2014-01-20 15:41) [135]Удалено модератором
← →
Jeer © (2014-01-20 15:48) [136]Удалено модератором
← →
Ega23 © (2014-01-20 15:53) [137]Удалено модератором
← →
Jeer © (2014-01-20 16:06) [138]KSDev давно взлетела, вместе с Крюковым и как раз из Улан-Удэ :)
← →
Слава Пестов (2014-01-20 16:17) [139]
> Вот говорят, что дельфи не умирает
Программируйте на "Фактор"
← →
DevilDevil © (2014-01-20 16:41) [140]Я считаю маркетологи Борланда, а потом Абракадабры слишком слабо трудятся над популяризацией проекта. FMX и кроссплатформ - это правильный путь. Но этого мало. К тому же качество созданной RAD Studio не очень высокое. Меня например просто бесит время компиляции и огромный размер exe-шника (читай время компиляции и запуска). Поэтому я до сих пор использую Delphi6 и 7. Вот это тема!
← →
Jeer © (2014-01-20 16:52) [141]Да я вообще сделал пару-тройку проектов на D7 и raudus - полет нормальный, хоть в интра-, хоть в экстра-Нете.
← →
DVM © (2014-01-20 16:59) [142]
> DevilDevil © (20.01.14 16:41) [140]
> Меня например просто бесит время компиляции
Ты что говоришь то? В Delphi еще какой быстрый компилятор. Ты погляди на скорость компиляции C++ проектов - сутки может продолжаться компиляция BOOST какого нибудь.
> и огромный размер exe-шника
Плата за удобство проектирования и все свое нашу с собой. Ему не надо 300 гиг фреймворка, ему не надо бесчисленных mfcxxx.dll точно таких версий и т.д.
← →
Jeer © (2014-01-20 17:02) [143]>Ты что говоришь то? В Delphi еще какой быстрый компилятор.
Да DD все еще витает в своих собственных фантазиях, хотя уже вроде пора менять короткие штанишки на приличные брюки:)
← →
И. Павел © (2014-01-20 17:02) [144]Предлагаю ввести праздник — день смерти дельфи. Каждый год программисты на дельфи будут отмечать его, размещая посты «дельфи мертв» во всевозможных интернет-ресурсах. Также предусматриваются поминки дельфи: 9 и 40 дней. Желательно включить праздник в ТК РФ, чтобы был выходным для тех, кто пишет на дельфи не менее 1000 строк в год.
← →
Jeer © (2014-01-20 17:05) [145]Нифига не дождетесь такого праздника - я перейду на D1 и завалю клиентов приложениями:)
Вот, насчет Праздника - это да, надо обдумать и обратиться к Законодателям.
← →
Ega23 © (2014-01-20 17:07) [146]
> Предлагаю ввести праздник — день смерти дельфи
ДА!!!!!!!!!!!!!!!
Это тема!!!!
← →
Ega23 © (2014-01-20 17:09) [147]Только это... Тут посовещались, и Розыч сказал, что 9 и 40 дней - это как-то православно.
Надо 8 и 32.
← →
DevilDevil © (2014-01-20 17:09) [148]> Ты что говоришь то? В Delphi еще какой быстрый компилятор.
> Ты погляди на скорость компиляции C++ проектов - сутки
> может продолжаться компиляция BOOST какого нибудь.
Я 2.5 года официально работал на С++
Зарёкся больше не работать на нём
Всё, что дольше секунды - долго
Вот Delphi 6 и 7 - тема. А XE уже нет
> Плата за удобство проектирования и все свое нашу с собой.
> Ему не надо 300 гиг фреймворка, ему не надо бесчисленных
> mfcxxx.dll точно таких версий и т.д.
В Delphi до сих пор очень глупый компилятор. Ну по сегодняшним меркам точно. Добавляет он вещи, которые теоретически можно не добавлять (виртуальные всякие шняжки и т.д.)
← →
имя (2014-01-20 17:11) [149]Удалено модератором
← →
vuk © (2014-01-20 17:14) [150]to DevilDevil © (20.01.14 16:41) [140]:
> Меня например просто бесит время компиляции и огромный размер
> exe-шника
Вот генерило бы оно код вместо dfm-ов, еще бы и эта проблема отчасти решилась. :) Но этого не будет.
← →
DevilDevil © (2014-01-20 17:19) [151]> Вот генерило бы оно код вместо dfm-ов, еще бы и эта проблема
> отчасти решилась. :) Но этого не будет.
и я про то
ещё не плохо бы, чтобы не все virtual/dinamic линковались, а только вызываемые. Тоже размер бы поубавился
← →
Inovet © (2014-01-20 17:21) [152]> [151] DevilDevil © (20.01.14 17:19)
> чтобы не все virtual/dinamic линковались, а только вызываемые
О как. И как такое возможно?
← →
имя (2014-01-20 17:23) [153]Удалено модератором
← →
DevilDevil © (2014-01-20 17:24) [154]> Inovet © (20.01.14 17:21) [152]
type
TSome = class
procedure A; virtual;
procedure B; virtual;
procedure C; virtual;
end;
procedure Test;
begin
with TSome.Create do
begin
A;
Free;
end;
end;
← →
Sapersky (2014-01-20 17:28) [155]
> Меня например просто бесит время компиляции
Прогнал rebuild одного проекта на D5 (7-ки нет в рабочем состоянии), 2010 и XE3:
D5 - 15 c.
2010/XE3 - 6-7 c.
Причём D5 ещё побыстрее 7-ки, у той компилятор вообще самый медленный во всей серии, возможно из-за многочисленных unsafe warnings или из-за попыток прикрутить кроссплатформенность.
← →
Kerk © (2014-01-20 17:40) [156]
> DevilDevil © (20.01.14 17:19) [151]
>
> > Вот генерило бы оно код вместо dfm-ов, еще бы и эта проблема
> > отчасти решилась. :) Но этого не будет.
>
> и я про то
> ещё не плохо бы, чтобы не все virtual/dinamic линковались,
> а только вызываемые. Тоже размер бы поубавился
Благодаря RTTI компилятор ни малейшего понятия не имеет о том, какие методы вызываемые, а какие нет. Точнее он знает какие методы точно вызываемые, а вот какие точно не вызываемые он даже предположить не может.
← →
имя (2014-01-20 17:47) [157]Удалено модератором
← →
DVM © (2014-01-20 17:49) [158]
> vuk © (20.01.14 17:14) [150]
> to DevilDevil © (20.01.14 16:41) [140]:
>
> > Меня например просто бесит время компиляции и огромный
> размер
> > exe-шника
>
> Вот генерило бы оно код вместо dfm-ов, еще бы и эта проблема
> отчасти решилась. :) Но этого не будет.
Все наоборот от кода (было, например в WinForms такое) к описанию стремятся (xaml например, файлы Qt designer), а тут обратное предлагается. Да и че они весят то dfm те, тьфу. Картинки включенные в ресурсы меньше все равно не станут.
← →
DVM © (2014-01-20 17:50) [159]
> Слава Пестов (20.01.14 17:47) [157]
Слава, а почему бы тебе для рекламы своего языка не сделать в дополнение к статье в википедии еще и форум factormaster.ru ?
← →
Sergey Masloff (2014-01-20 17:51) [160]Слава Пестов (20.01.14 17:47) [157]
>Фактор - 3 с
Рекламо детектед. Ты даже не знаешь что за проект но вот 3 с заявляешь уверенно ;-)
← →
vuk © (2014-01-20 17:54) [161]to DVM © (20.01.14 17:49) [158]:
> Да и че они весят то dfm те, тьфу. Картинки включенные в
> ресурсы меньше все равно не станут.
В том виде, в каком они есть, они только мешают, причем, очень сильно при использовании тех же фреймов.
Да, картинки в ресурсах отторжения не вызывают. :)
← →
имя (2014-01-20 17:55) [162]Удалено модератором
← →
XCoder (2014-01-20 18:07) [163]Как-то поставили задачу написать несколько небольших информационных приложений под iOS. Решили заюзать хваленый FMX. Стали писать - наловили кучу багов, инфы, как их обойти - никакой. В итоге выкинули весь этот FMX нафиг. Зря потраченные деньги.
← →
имя (2014-01-20 18:09) [164]Удалено модератором
← →
DevilDevil © (2014-01-20 18:16) [165]> Благодаря RTTI компилятор
не надо мне рассказывать про RTTI :)
я знаю немножко больше :)
← →
Jeer © (2014-01-20 18:23) [166]Программируйте на ABCPascal!
← →
Kerk © (2014-01-20 18:26) [167]
> DevilDevil © (20.01.14 18:16) [165]
Ну вот понесло... Я не сомневаюсь, что ты знаешь большего любого незнакомого тебе человека, которого ты случайно встретил в интернете. Ты вообще знаешь больше всех.
Компилятор никак не сможет определить факт вызова метода, если он вызван с помощью RTTI. Это просто факт вроде того, что сейчас январь. Я сам бывает в момент компиляции не знаю, какие методы мой код будет вызывать.
← →
имя (2014-01-20 18:27) [168]Удалено модератором
← →
DevilDevil © (2014-01-20 18:32) [169]> Kerk © (20.01.14 18:26) [167]
ты неправильно понял
я сказал конкретно про RTTI
← →
имя (2014-01-20 18:40) [170]Удалено модератором
← →
Kerk © (2014-01-20 18:44) [171]
> DevilDevil © (20.01.14 18:32) [169]
Я может быть к концу рабочего дня начинаю плохо понимать людей. Это бывает.
← →
Eraser © (2014-01-21 01:07) [172]
> XCoder (20.01.14 18:07) [163]
слабонервные ;-)
← →
jumping jack (2014-01-21 08:28) [173]> Компилятор никак не сможет определить факт вызова метода, если он вызван с помощью RTTI.
да, хотя теоретически компилятор мог бы обнаруживать полное отсутствие вызовов с помощью RTTI и для этих случаев линковать иначе - может быть, это DevilDevil имел в виду?
но, поскольку VCL завязан на загрузку свойств компонентов из DFM через RTTI и варианты без неё никто серьезно не рассматривал и не рассматривает, это опять же из серии маниловских мечтаний (однако, есть KOL - DevilDevil, как тебе он?)
← →
DevilDevil © (2014-01-21 16:40) [174]> Kerk © (20.01.14 18:26) [167]
> jumping jack (21.01.14 08:28) [173]
Если говорить о самых элементарных усовершенствованиях компилятора, то существенно уменьшить размер можно было бы, проработав всего 2 момента.
1) это конечно выслеживание, какие именно виртуальные и динамические вызовы производятся, а не линковать все
2) иная политика published и dfm. Пусть отныне свойства и функции, объявленные в published не будут заноситься в RTTI, но сохраняют роль отображаемых в Object Inspector. DFM-ки нужно компилировать в исполняемый код.
Таким образом размер приложений существенно сократится.
> однако, есть KOL - DevilDevil, как тебе он?
Отличный проект в нише созданных на энтузиазме.
Но там нет FMX. А для VCL-like приложений меня устраивают стандартные решения
← →
Kerk © (2014-01-21 16:46) [175]
> DevilDevil © (21.01.14 16:40) [174]
> это конечно выслеживание, какие именно виртуальные и динамические
> вызовы производятся, а не линковать все
Каким образом, как ты считаешь, это выслеживание возможно? Я сходу не вижу никаких способов. Кроме разве что директивы компилятора "выключи RTTI". Так она по-моему уже есть.
> 2) иная политика published и dfm. Пусть отныне свойства
> и функции, объявленные в published не будут заноситься в
> RTTI, но сохраняют роль отображаемых в Object Inspector.
> DFM-ки нужно компилировать в исполняемый код.
В RTTI заносятся не только published члены класса, в RTTI заносятся все члены класса уже года четыре как минимум.
← →
DevilDevil © (2014-01-21 16:51) [176]> Каким образом, как ты считаешь, это выслеживание возможно?
> Я сходу не вижу никаких способов. Кроме разве что директивы
> компилятора "выключи RTTI". Так она по-моему уже есть.
виртуальные и динамические методы не имеют ничего общего с RTTI
а отслеживать их вызов можно таким же образом как статические (что на данный момент делается не плохо)
посмотри ещё раз [154]
> В RTTI заносятся не только published члены класса, в RTTI
> заносятся все члены класса уже года четыре как минимум.
Вот поэтому мне и не нравится XE
Поэтому я пользую Delphi6 и Delphi7
← →
Object Inspector (2014-01-21 16:52) [177]> Пусть отныне свойства и функции, объявленные в published не будут
> заноситься в RTTI, но сохраняют роль отображаемых в Object Inspector.
А как их отобразить без RTTI?
← →
DVM © (2014-01-21 16:57) [178]
> DevilDevil © (21.01.14 16:40) [174]
> DFM-ки нужно компилировать в исполняемый код.
> Таким образом размер приложений существенно сократится.
Чего вам эти Dfm дались то? Ну вот что реально даст их преобразование в исполняемый код? Я точно могу казать, что размер не уменьшится от этого.
Всю дорогу были и будут ресурсы, в которых хранились диалоговые окна и никто их не компилил в исполняемый код, а пользовались функциями создания окна из ресурса. Dfm - просто свой вариант ресурса с описанием диалогового окна.
← →
Object Inspector Conscience (2014-01-21 16:58) [179]> А как их отобразить без RTTI?
Компоненты компилятся в отдельные bpl-и, код которых, если не сильно изворачиваться, не попадает в exe. В design-time bpl вполне можно published трактовать как RTTI. Но есть и другие способы.
← →
Kerk © (2014-01-21 17:01) [180]
> DevilDevil © (21.01.14 16:51) [176]
> виртуальные и динамические методы не имеют ничего общего с RTTI
> а отслеживать их вызов можно таким же образом как статические (что на данный момент делается не плохо)
> посмотри ещё раз [154]
Раз мы никак друг друга не можем понять, я потрудился сделать небольшой пример. Поставь себя на место компилятора и определи какие методы класса TSome вызываются, а какие - нет.program Project2;
{$APPTYPE CONSOLE}
{$R *.res}
uses
System.SysUtils, System.Rtti;
type
TSome = class
procedure A; virtual;
procedure B; virtual;
procedure C; virtual;
end;
procedure TSome.A;
begin
WriteLn("A");
end;
procedure TSome.B;
begin
WriteLn("B");
end;
procedure TSome.C;
begin
WriteLn("C");
end;
procedure Test(const MethodName: string);
var
RttiContext: TRttiContext;
RttiType: TRttiType;
RttiMethod: TRttiMethod;
MyClass: TSome;
begin
MyClass := TSome.Create;
try
RttiContext := TRttiContext.Create;
RttiType := RttiContext.GetType(MyClass.ClassInfo);
RttiMethod := RttiType.GetMethod(MethodName);
if Assigned(RttiMethod) then
RttiMethod.Invoke(MyClass, [])
else
WriteLn("Method not found");
RttiContext.Free;
finally
MyClass.Free;
end;
end;
begin
try
Test(ParamStr(1));
ReadLn;
except
on E: Exception do
Writeln(E.ClassName, ": ", E.Message);
end;
end.
Проверялось в XE5.
← →
DevilDevil © (2014-01-21 17:02) [181]> Чего вам эти Dfm дались то? Ну вот что реально даст их преобразование
> в исполняемый код? Я точно могу казать, что размер не уменьшится
> от этого.
> Всю дорогу были и будут ресурсы, в которых хранились диалоговые
> окна и никто их не компилил в исполняемый код, а пользовались
> функциями создания окна из ресурса. Dfm - просто свой вариант
> ресурса с описанием диалогового окна.
DFM - это ресурс. Который можно открыть и отредактировать в редакторе ресурсов. Например список изменяемых свойств.
Такая концепция располагает к тому, что все published-свойства должны быть универсально изменяемы, а значит каждое из них линкуется. Если dfm преобразовывать в линкованный код, а published не заносить в RTTI - тогда сразу становится видно, какой код нужен, а какой линковать нет необходимости
← →
DevilDevil © (2014-01-21 17:04) [182]> Раз мы никак друг друга не можем понять, я потрудился сделать
> небольшой пример. Поставь себя на место компилятора и определи
> какие методы класса TSome вызываются, а какие - нет.
Твои рассуждения идут из соображения, что все методы класса должны попасть в RTTI
Мои рассуждения идут из соображения, что не имеет смысла тащить всё в RTTI и линковку. Это зло.
← →
Kerk © (2014-01-21 17:06) [183]
> DevilDevil © (21.01.14 17:04) [182]
Причем тут чьи-то соображения? Я дал простой код. Представь себя компилятором, назови неиспользуемые методы класса TSome и мы не будем включать их в линковку. Все ведь очень просто.
← →
DevilDevil © (2014-01-21 17:07) [184]> Kerk © (21.01.14 17:06) [183]
Я представил себя компилятором и увидел, что класс TSome вообще не содержит RTTI-методов.
← →
DevilDevil © (2014-01-21 17:10) [185]Да, ни A, ни B, ни C не вызывается - значит их не нужно прилинковывать
← →
Kerk © (2014-01-21 17:12) [186]
> DevilDevil © (21.01.14 17:07) [184]
>
> > Kerk © (21.01.14 17:06) [183]
>
> Я представил себя компилятором и увидел, что класс TSome
> вообще не содержит RTTI-методов.
Ну тогда ты не компилятор Delphi, ты какой-то другой компилятор. Потому что в Delphi все отлично работает и замечательно вызываются все три метода.
← →
Kerk © (2014-01-21 17:12) [187]Ты похоже предлагаешь отказаться от мощнейшего функционала, ради экономии жалких нескольких мегабайт на диске. Но то, что тебе это не нужно, совсем не означает, что это никому не нужно. К тому же если совсем приперло, то видимостью методов в RTTI можно управлять директивами компилятора.
← →
vuk © (2014-01-21 17:13) [188]to DVM © (21.01.14 16:57) [178]:
> Dfm - просто свой вариант ресурса с описанием диалогового окна.
Оно не совсем так. Ресурс диалогового окна не привязан к коду приложения и никак не влияет на другие ресурсы. А dfm - привязан и до кучи может влиять на другие dfm. Задница начинается, когда меняются часто используемые фреймы, особенно если они в свою очередь используются в других фреймах и т.д. Из-за минимального изменения в одном фрейме приходится зачастую доставать из VCS и править до десятка (иногда и больше) других модулей, где он засветился, как вложенный. Причем нормально правится это иной раз только залезанием в dfm руками и выпиливанием лишнего. Из-за этих проблем особо сложные фреймы приходится создавать динамически. Проблема обрисовалась с выходом Delphi 5. Это сколько версий назад? Больше десятка.
← →
DevilDevil © (2014-01-21 17:14) [189]> Ну тогда ты не компилятор Delphi, ты какой-то другой компилятор.
> Потому что в Delphi все отлично работает и замечательно
> вызываются все три метода.
Ты говоришь про Delphi сейчас. Delphi XE и иже с ними. Delphi которые мне НЕ НРАВЯТСЯ. А в тех Delphi, которые мне нравились - в них методы A, B и C в RTTI не попадали. Я об этом и говорю
← →
Ega23 © (2014-01-21 17:17) [190]Удалено модератором
← →
DevilDevil © (2014-01-21 17:19) [191]> Kerk © (21.01.14 17:12) [187]
> Ты похоже предлагаешь отказаться от мощнейшего функционала,
> ради экономии жалких нескольких мегабайт на диске. Но то,
> что тебе это не нужно, совсем не означает, что это никому
> не нужно. К тому же если совсем приперло, то видимостью
> методов в RTTI можно управлять директивами компилятора.
И да и нет
Я считаю что подобный функционал имеет место быть но ДАЛЕКО не в каждом классе. Я считаю программист сам в состоянии определить, какие именно методы и свойства должны попадать в RTTI.
И дело не в жалких нескольких мегабайтах. Дело в бесценном времени программиста и пользователя, каждый божий раз затрачиваемых на компиляцию и загрузку никогда не использующихся мегабайтов
← →
DevilDevil © (2014-01-21 17:20) [192]Удалено модератором
← →
Ega23 © (2014-01-21 17:22) [193]
> на что предлагаешь поспорить ?
Что в D7 можно будет вызвать методы A, B и C классаtype
TSome = class
procedure A; virtual;
procedure B; virtual;
procedure C; virtual;
end;
через RTTI?
← →
Kerk © (2014-01-21 17:24) [194]
> DevilDevil © (21.01.14 17:19) [191]
> И дело не в жалких нескольких мегабайтах. Дело в бесценном
> времени программиста и пользователя, каждый божий раз затрачиваемых
> на компиляцию и загрузку никогда не использующихся мегабайтов
Это на какую-то религию похоже. Тебе нравится думать об экономии каких-то долей микросекунды на каждом запуске. А я лучше буду думать о том, что в D7 такую штуку как мой DelphiSpec в полной мере сделать в принципе невозможно. Причем, как ты понимаешь, DelphiSpec - это не единственное для чего человечество додумалось использовать новый RTTI. Так что даже не знаю что ценней... экономия долей микросекунд или новый мощный функционал экономящий силы и время.
← →
DevilDevil © (2014-01-21 17:25) [195]> через RTTI?
только если поставить {$M+}
в исходном виде - нет
а если поставишь public - то не пропадут точно
но прилинкуются
ибо виртуальные
← →
DevilDevil © (2014-01-21 17:31) [196]> Это на какую-то религию похоже. Тебе нравится думать об
> экономии каких-то долей микросекунды на каждом запуске.
> А я лучше буду думать о том, что в D7 такую штуку как мой
> DelphiSpec в полной мере сделать в принципе невозможно.
> Причем, как ты понимаешь, DelphiSpec - это не единственное
> для чего человечество додумалось использовать новый RTTI.
> Так что даже не знаю что ценней... экономия долей микросекунд
> или новый мощный функционал экономящий силы и время.
Согласись было бы неправильно, если бы я сказал, что DelphiSpec говно потому, что его нельзя использовать совместно с D7?
Ты же сейчас поступаешь примерно таким образом. Мессейдж выглядит как "D7 говно потому, что его нельзя использовать с DelphiSpec; и плевать, что проект компилится значительно дольше, а экзешники весят много мегабайт".
Я думаю, рассуждая о том, что правильно - следует искать оптимальное решение, которое покрывало бы задачи быстрой компактной компиляции и использование такой мощной вещи как DelphiSpec.
В качестве оптимального решения я вижу опция компилятора "забубенить все методы в RTTI", которая по умолчанию была бы выключена. А включать её нужно было бы перед тестированием на DelphiSpec.
← →
Kerk © (2014-01-21 17:41) [197]
> DevilDevil © (21.01.14 17:31) [196]
Я просто считаю, что лучше больше возможностей, чем меньше :)
> В качестве оптимального решения я вижу опция компилятора
> "забубенить все методы в RTTI", которая по умолчанию была
> бы выключена.
Так есть же много директив компилятора, которые позволяют управлять RTTI. Разве что они по умолчанию выключены. Так что тебе мешает их включить?
Пишешь {$WEAKLINKRTTI ON} и компилятор смело выкидывает неиспользуемые прямо в коде методы, забывая, что есть еще и RTTI (но уж не знаю что там будет с нелюбимыми тобой виртуальными функциями:)
Пишешь {$RTTI EXPLICIT METHODS([vcPublished]) PROPERTIES([vcPublished])} и в RTTI попадают только published методы и свойства соответствующего класса.
Проблема только в том, что оно не по умолчанию?
← →
DevilDevil © (2014-01-21 17:48) [198]> Я просто считаю, что лучше больше возможностей, чем меньше :)
Я тоже за "больше возможностей"
Просто в данном случае мы говорим о возможностях, которые во-первых, нужны далеко не всегда, во-вторых, отжирают немеряно времени компиляции. Ну и мегабайтов на диске тоже. Почему ты игнорируешь аргумент с временем компиляции - не понятно. Лично меня этот момент просто выбешивает
> Так есть же много директив компилятора, которые позволяют
> управлять RTTI. Разве что они по умолчанию выключены. Так
> что тебе мешает их включить?
А задаются они только в тексте или в опциях проекта можно выставить ?
Если можно выставить - хорошо
Но это не решает проблем, которые тянутся наследнием с древнейших времён. Подходов, о которых я уже говорил
← →
Ega23 © (2014-01-21 18:41) [199]
> только если поставить {$M+}
> в исходном виде - нет
И в исходном виде - да, если {$M+} в настройках включен.
Я это к тому, что всё-таки можно.
> отжирают немеряно времени компиляции
Для Delphi такое выражение просто смешно.
← →
DevilDevil © (2014-01-21 19:38) [200]> И в исходном виде - да, если {$M+} в настройках включен.
> Я это к тому, что всё-таки можно.
напомни название опции, поищу
> Для Delphi такое выражение просто смешно.
ну для того кто не программирует - может и смешно
я постоянно перекомпилирую, дорабатываю, отлаживаю
← →
Ega23 © (2014-01-21 19:42) [201]
> напомни название опции, поищу
Я семёрку последний раз видел лет шесть назад.
> ну для того кто не программирует - может и смешно
> я постоянно перекомпилирую, дорабатываю, отлаживаю
А, ну так-то оно конечно да, тут один программист всего, я и забыл.
← →
Rouse_ © (2014-01-21 19:50) [202]
> DevilDevil © (21.01.14 17:48) [198]
> > Я просто считаю, что лучше больше возможностей, чем меньше
> :)
>
> Я тоже за "больше возможностей"
> Просто в данном случае мы говорим о возможностях, которые
> во-первых, нужны далеко не всегда, во-вторых, отжирают немеряно
> времени компиляции. Ну и мегабайтов на диске тоже. Почему
> ты игнорируешь аргумент с временем компиляции - не понятно.
> Лично меня этот момент просто выбешивает
Как давно ты делал полный билд проекта под MS VC++ ?
Если тебя выбешивает время компиляции под дельфей, то под студией ты должен как минимум пойти и застрелить разработчиков оной, пока проект билдится (и вероятно даже успеешь) :)
← →
Rouse_ © (2014-01-21 19:52) [203]ЗЫ: это я тебе так мягко намекаю, бо время полного ребилда того-же Notepad++ коим мы тут все привыкли пользоваться в районе двух с половиной часов.
← →
Пит (2014-01-21 20:06) [204]ага, поэтому у дельферов ярко выраженный стиль работы. Сделал галочку, жмякнул F9, посмотрел как она выглядит и работает, дальше программирует )))
← →
Ega23 © (2014-01-21 20:26) [205]
> Как давно ты делал полный билд проекта под MS VC++ ?
Это, помниццо, лет 5 назад с Алкидом нажрались как-то во вторник. Ну и по аське в среду, мол, как самочувствие? А он мне: "Да я поставил полный билд проекта и спать на руки лёг, часа 2 проспал".
Но я понимаю - Лёха-то ваще не программирует совсем.
← →
clickmaker © (2014-01-21 21:06) [206]> Да я поставил полный билд проекта и спать на руки лёг, часа
> 2 проспал
программер спит - таймшит идет
← →
Юрий Зотов © (2014-01-21 21:34) [207]> Object Inspector Conscience (21.01.14 16:58) [179]
> Компоненты компилятся в отдельные bpl-и
Это не новость.
> код которых, если не сильно изворачиваться, не попадает в exe.
Если компилить с run-time пакетами. А если нет (что бывает чаще), то вот это уже новость.
> В design-time bpl вполне можно published трактовать как RTTI.
У компонентов деление на run-time и design-time довольно таки условное. Кинутый на форму компонент УЖЕ работает точно так же, как он работает и в программе. Поэтому для компонента понятие design-time означает всего лишь то, что он работает в среде IDE, а не в среде программы.
> Но есть и другие способы.
Хотелось бы подробностей. Какими способами можно отобразить ЛЮБОЙ компонент в Object Inspector"е, не используя RTTI ?
← →
DevilDevil © (2014-01-21 23:12) [208]> Rouse_ © (21.01.14 19:50) [202]
> Как давно ты делал полный билд проекта под MS VC++ ?Если
> тебя выбешивает время компиляции под дельфей, то под студией
> ты должен как минимум пойти и застрелить разработчиков оной,
> пока проект билдится (и вероятно даже успеешь) :)
Приоткрою страницы своей биографии
Моя первая официальная работа программистом отняла у меня 2,5 года жизни. Если её вообще можно назвать жизнью. Я программировал на C++Builder. Это по хлеще вашей Visual Studio было ;)
← →
DevilDevil © (2014-01-21 23:12) [209]> Ega23 © (21.01.14 19:42) [201]
> > напомни название опции, поищуЯ семёрку последний раз видел
> лет шесть назад.
но тем не менее ты утверждаешь, что {$M+} там в опциях есть :)
← →
Ega23 © (2014-01-21 23:17) [210]
> Какими способами можно отобразить ЛЮБОЙ компонент в Object
> Inspector"е, не используя RTTI ?
Не, ну извратиться-то можно. Например, на уровне TComponent унаследовать какой-нить хитрый интерфейс IObjectInspectorProps, в котором уже вот это всё делать.
Но это лютый изврат на фоне существующего мощного механизма.
> Я программировал на C++Builder.
Среда как среда.
← →
Ega23 © (2014-01-21 23:20) [211]
> но тем не менее ты утверждаешь, что {$M+} там в опциях есть
Вот поверь, ради того, чтобы найти, где эта опция там в настройках включается, я не буду искать семёрку на торрентах и пытаться её локально развернуть.
Но уж ежели на {$B-} и {$B+} чекбокс сподобились запуздырить...
← →
DevilDevil © (2014-01-21 23:22) [212]> Юрий Зотов © (21.01.14 21:34) [207]
Юрий, я утверждаю, что поменяв всего несколько вещей в подходах, компания Embarcadero смогла бы легко сократить время компиляции и размер exe.
Те вещи, которые Вы комментируете - были ответом на вопрос "как тогда быть в design-time, если published свойства не будут попадать в RTTI (в real-time)"
Если после пояснения Вы всё же будете настаивать на вопросах [207] - я отвечу. Но хочется надеяться, в этом больше нет необходимости
← →
DevilDevil © (2014-01-21 23:25) [213]> Ega23 © (21.01.14 23:20) [211]
> Вот поверь, ради того, чтобы найти, где эта опция там в
> настройках включается, я не буду искать семёрку на торрентах
> и пытаться её локально развернуть.Но уж ежели на {$B-} и
> {$B+} чекбокс сподобились запуздырить...
Я тебе мягко намекаю на то, что твои выпады были бы адекватны, если бы на них были основания. Но оснований нет
← →
Ega23 © (2014-01-21 23:45) [214]А может и нет такой галки.
Только один хрен TPersistent под {$M+} объявлен.
← →
DevilDevil © (2014-01-21 23:46) [215]но не TObject, от которого наследуется TSome
← →
Ega23 © (2014-01-21 23:48) [216]
> но не TObject, от которого наследуется TSome
Не тот. Ну а толку-то?
Не, можно, конечно, написать свои компоненты, с шахматами и поэтессами. А смысл?
← →
DevilDevil © (2014-01-21 23:54) [217]Смысл в том, чтобы согласиться с высказываниями [184] и [185]
И впредь проявлять чуть большее уважения к высказываниям форумчан
← →
Юрий Зотов © (2014-01-22 00:02) [218]> Ega23 © (21.01.14 23:17) [210]
Олег, попробуй определить интерфейс IObjectInspectorProps - так, чтобы с его помощью можно было отобразить в Object Inspector ЛЮБЫЕ свойства ЛЮБОГО компонента. В том числе, ЛЮБОГО самописного.
> Ega23 © (21.01.14 23:20) [211]
Директива {$M+} явно прописана прямо в коде VCL, в модуле Classes, непосредственно перед объявлением TPersistent (по крайней мере, в D1-D7). И понятно, почему - потому что именно от TPersistent наследуется все то, что отображается в IDE.
> DevilDevil © (21.01.14 23:22) [212]
1. В сокращении времени компиляции нет никакой необходимости, в Delphi оно и без того мало. Овчинка не стоит выделки.
2. Все же мне хотелось бы увидеть пример отображения в Object Inspector ЛЮБЫХ свойств ЛЮБОГО компонента без использования RTTI. Я действительно не представляю, как это можно сделать.
← →
vuk © (2014-01-22 00:12) [219]to Юрий Зотов © (22.01.14 00:02) [218]:
> Все же мне хотелось бы увидеть пример отображения в Object
> Inspector ЛЮБЫХ свойств ЛЮБОГО компонента без использования
> RTTI. Я действительно не представляю, как это можно сделать.
>
Что-то типа IDispatch и иже с ним?
← →
DevilDevil © (2014-01-22 00:24) [220]> Юрий Зотов © (22.01.14 00:02) [218]
> 1. В сокращении времени компиляции нет никакой необходимости,
> в Delphi оно и без того мало. Овчинка не стоит выделки.
Видимо для Вас это не на столько критично, насколько для меня. Всё, что дольше секунды - для меня долго. Поэтому я не пересаживаюсь на XE
> 2. Все же мне хотелось бы увидеть пример отображения в Object
> Inspector ЛЮБЫХ свойств ЛЮБОГО компонента без использования
> RTTI. Я действительно не представляю, как это можно сделать.
Ну пример Вы врядли увидите, но описать один из возможных вариантов такой реализации я в состоянии. Обусловимся, что в design-time bpl-е компилируются все published-свойства. Соответственно при компиляции Delphi знает о каждом свойстве - как получается, как изменяется. Соответственно по каждому свойству хранится 2 указателя на функцию - одна геттер, другая сеттер. Если свойство реально использует геттер или сеттер тогда указатель содержит реально скомпилированную функцию. Если свойство читается/изменяется по полю - тогда генерируется JIT функция, взаимодействующая непосредственно с полем.
Согласен, путь published RTTI в design-time выглядит проще всего. Но и вариант, описанный выше, - тоже имеет право на существование
← →
Дмитрий Белькевич (2014-01-22 00:26) [221]Реально не знаю, что ты, DevilDevil, такое там собираешь. Наш самый толстый проект. 790 тысяч строк, 44 формы, build около 10-ти секунд, compile - 4. D2010. По-моему резульататы отличные. Мне особенно сравнивать не с чем, я кроме как с Delphi ни с чем не работал, но меня скорость компиляции вполне устраивает. Опять же - всё таки написание программ (по крайней мере у меня :) ) отнимает достаточно много времени в раздумиях, написании кода и отладке. Компилирую не очень часто, build так вообще может быть раз в 3-4 дня или реже. У каждого свой стиль, конечно. Но на мой взгляд время компиляции в delphi отличное.
У себя давно сделал:
{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([]) FIELDS([]) PROPERTIES([])}
← →
Дмитрий Белькевич (2014-01-22 00:30) [222]По поводу размера. Размеры экзешников под Андроид, скажем так, удивили :)
Есть у нас один проект - справочник, размер довольно критичен при установке "по воздуху". И качать 20-ти мегабайтную программу, скорее всего, не станут.
Сейчас программа занимает 400 кб, я не сам ей занимаюсь, была бы возможность - то пересобрал бы её на Delphi, но размер экзешника сдерживает.
← →
Юрий Зотов © (2014-01-22 00:31) [223]> vuk © (22.01.14 00:12) [219]
То есть, каждый компонент становится COM-сервером?
← →
DevilDevil © (2014-01-22 00:32) [224]> Дмитрий Белькевич (22.01.14 00:26) [221]
1 секунда лучше, чем 10, согласись ? :)
а вообще я не навязываю свои пристрастия другим людям. Я говорю, что, поменяв концепцию, можно добиться лучших результатов, проработав всего 2 пункта. Вас устраивает, меня нет. Вы выбираете, я остаюсь на Delphi 7. Вот и всё. :)
← →
Юрий Зотов © (2014-01-22 00:36) [225]> DevilDevil © (22.01.14 00:24) [220]
А где же отображение в Object Inspector?
← →
vuk © (2014-01-22 00:42) [226]to Юрий Зотов © (22.01.14 00:31) [223]:
> То есть, каждый компонент становится COM-сервером?
COM - вполне себе компонентная модель, работающая через интерфейсы. Я не говорю, что делать надо именно так. Не надо. :) Но ты спросил - и вот тебе вариант ответа.
← →
DevilDevil © (2014-01-22 00:44) [227]> Юрий Зотов © (22.01.14 00:36) [225]
Понятно, к чему Вы клоните - к тому, что без RTTI никак
И Вы правы
Просто произнося аббревиатуру "RTTI" я подразумеваю непосредственно дельфийский PTypeInfo. И говоря "есть и другие способы", я подразумевал, что можно не использовать Delphi-подход, ставший стандартом
Разумеется в добавок к методу, описанному выше, понадобятся имена свойств и описания их типов. Что технически разумеется подпадает под истинную расшифровку аббревиатуры "RTTI"
← →
Дмитрий Белькевич (2014-01-22 00:47) [228]>1 секунда лучше, чем 10, согласись ? :)
Лучшее враг хорошего, как известно. Почему одна? Почему не 100 мс? Не 10 мс? Не 10 нс? Как на мой вкус, то билд за 10 секунд и компиляция за 3-4 это отличный результат. Ну а нужен реально экстремально быстрый билд - то сиди на 7-ке, кто же тебя выше тянет :) Если бы не юникод и (уже) 64 бита я бы сам на 7-ке сидел.
← →
DevilDevil © (2014-01-22 00:51) [229]> Лучшее враг хорошего, как известно.
только не у перфекционистов
у нас плохо - если не так хорошо, как мог сделать :)
> Почему одна?
потому что, нажимая F9, разница между половиной секунды и одной секундой - не ощутима. А разница между одной секундой и тремя - уже ощутима. В моём случае она конкретно бесит.
← →
Ega23 © (2014-01-22 01:07) [230]Для этого есть Syntax Check.
← →
Пит (2014-01-22 01:10) [231]
> Всё, что дольше секунды - для меня долго
нифига ты быстрый.
← →
jumping jack (2014-01-22 01:12) [232]байзэвэй, говорят, в дотнете (как и других языках/средах с возможностью интерпретации кода) возможно такое чудо, как изменение кода прямо в процессе отладки, на ходу, без перекомпиляции
вот уж где скорость отладки-то реально хороша
← →
имя (2014-01-22 01:13) [233]Удалено модератором
← →
Юрий Зотов © (2014-01-22 01:14) [234]> vuk © (22.01.14 00:42) [226]
Вариант, согласен.
:o)
> DevilDevil © (22.01.14 00:44) [227]
Ну, наверное можно что-то придумать и взамен RTTI. Vuk же предложил вариант. И ведь действительно работать будет. Но какими тогда станут те самые размер кода и время компиляции?
А RTTI - просто, быстро, универсально. И зачем, спрашивается, от него уходить?
← →
antonn © (2014-01-22 08:06) [235]
> jumping jack (22.01.14 01:12) [232]
>
> байзэвэй, говорят, в дотнете (как и других языках/средах
> с возможностью интерпретации кода) возможно такое чудо,
> как изменение кода прямо в процессе отладки, на ходу, без
> перекомпиляции
ну да, удобно, однако работая с несколькими языками все таки привычно по-старинке (а иногда и тупыми мессаджбоксами =))
← →
Sergey Masloff (2014-01-22 09:20) [236]DevilDevil © (22.01.14 00:32) [224]
>> Дмитрий Белькевич (22.01.14 00:26) [221]
>1 секунда лучше, чем 10, согласись ? :)
Можно я не соглашусь? Это вообще без разницы. Проект компилируется 1 раз в день, ну 10 раз... 100 раз ни разу не компилировал. Экономия 9 секунд не стоит вложений. Ни копейки.
Ну теоретически если б она была абсолютно бесплатной то 1 лучше чем 10. Практически - монопенисуально. Свои ресурсы лучше потратить на что-то более полезное...
← →
имя (2014-01-22 09:28) [237]Удалено модератором
← →
DevilDevil © (2014-01-22 09:37) [238]> Юрий Зотов © (22.01.14 01:14) [234]
> Ну, наверное можно что-то придумать и взамен RTTI. Vuk же
> предложил вариант. И ведь действительно работать будет.
> Но какими тогда станут те самые размер кода и время компиляции?
>
> А RTTI - просто, быстро, универсально. И зачем, спрашивается,
> от него уходить?
Вы говорите так, будто COM не подразумевает под собой RTTI :)
Те же имена свойств/методов, указатели на них, информация о типах :)
> Но какими тогда станут те самые размер кода и время компиляции?
design-time bpl-и традиционно большие. Но из них ни байта не попадает в exe. Exe компилируется и линкуется из исходников, design-time bpl работает в IDE. Поэтому логично, что для design-time и для exe должны быть применены разные политики RTTI. Ибо для design-time нужны все свойства и события, а для exe - только малая часть из них.
← →
vuk © (2014-01-22 10:15) [239]to DevilDevil © (22.01.14 09:37) [238]:
> а для exe - только малая часть из них.
Засада только одна - это неизвестно, какая часть.
← →
DevilDevil © (2014-01-22 10:23) [240]> vuk © (22.01.14 10:15) [239]
> Засада только одна - это неизвестно, какая часть.
На дворе 21 век. И современные компиляторы вполне успешно справляются с задачей определения, какой код прилинковывать, а какой нет :)
← →
vuk © (2014-01-22 10:25) [241]to DevilDevil © (22.01.14 10:23) [240]:
> И современные компиляторы вполне успешно справляются с
> задачей определения, какой код прилинковывать, а какой нет
> :)
Компиляторы научились заглядывать настолько вперед, что знают, какое свойство у них запросят через RTTI?
← →
DevilDevil © (2014-01-22 10:35) [242][174]
← →
vuk © (2014-01-22 10:38) [243]И что? То что там написано относительно RTTI - чушь.
← →
DevilDevil © (2014-01-22 10:39) [244]очень сильный аргумент, товарищ vuk :)
← →
vuk © (2014-01-22 10:49) [245]Хорошо, буду задавать вопросы.
> Пусть отныне свойства и функции, объявленные в published
> не будут заноситься в RTTI, но сохраняют роль отображаемых
> в Object Inspector.
>
Каким макаром? Святым духом?
До кучи. Ощущение, что у вас нет понимания, зачем вообще нужен механизм RTTI. А ведь он подразумевает обращение к произвольным свойствам посредством полученной от компонента информации. Поэтому то, что объявлено, как доступное через RTTI обязано включаться безусловно. Да и компонентные модели подразумевают неделимость компонентов.
А от замены dfm на код я и сам бы не отказался, но только по совершенно другим причинам. Причем, при сохранении текущей компонентной модели и RTTI. Размер exe меня не волнует на данный момент, ну вот совсем. У меня он больше 50 мегабайт и я не парюсь. :)
← →
Ega23 © (2014-01-22 10:54) [246]
> На дворе 21 век. И современные компиляторы вполне успешно
> справляются с задачей определения, какой код прилинковывать,
> а какой нет :)
Да. И оптимизируют очень неплохо, в отличие от дельфёвого. Только вот время билда - 2 часа, заместо 10 секунд.
← →
Inovet © (2014-01-22 11:00) [247]> [246] Ega23 © (22.01.14 10:54)
> Только вот время билда — 2 часа, заместо 10 секунд.
Нужен оптимизатор оптимизации.
← →
DevilDevil © (2014-01-22 11:01) [248]> Ega23 © (22.01.14 10:54) [246]
> Да. И оптимизируют очень неплохо, в отличие от дельфёвого.
> Только вот время билда - 2 часа, заместо 10 секунд.
Открою тайну. Delphi с бородатой версии не линкует не используемые статические функции и данные типа глобальных переменных
← →
DevilDevil © (2014-01-22 11:08) [249]> vuk © (22.01.14 10:49) [245]
блин
говорю ведь об элементарных вещах
формула обхода RTTI очень проста
а) не нужно всё подряд пихать в RTTI (как в текущих версиях)
б) published свойства идут в RTTI в design-time bpl-и, но для run-time published в RTTI не идёт
в) dfm-ки переводятся в статический код
что здесь сложного и из ряда вон выходящего ?
в run-time RTTI по свойствам и методам нужен крайне редко. Поэтому и включать его в run-time нужно при наличии каких-то специальных опций, а не по дефолту, как это делается сейчас
← →
Василий Иванов (2014-01-22 11:13) [250]
> Поэтому и включать его в run-time нужно при наличии каких-
> то специальных опций, а не по дефолту, как это делается
> сейчас
наконец-то дошли до сути
← →
vuk © (2014-01-22 11:15) [251]to DevilDevil © (22.01.14 11:08) [249]:
> published свойства идут в RTTI в design-time bpl-и, но для
> run-time published в RTTI не идёт
Что идет вразрез с правилом неделимости компонентов и делает невозможным обращение к произвольным свойствам.
← →
имя (2014-01-22 11:20) [252]Удалено модератором
← →
Ega23 © (2014-01-22 11:25) [253]
> Открою тайну. Delphi с бородатой версии не линкует не используемые
> статические функции и данные типа глобальных переменных
Надо линковать, тогда ещё быстрее будет. И оптимизатор выключить. Тогда до секунды той самой дойдёт.
← →
DevilDevil © (2014-01-22 11:27) [254]> Ega23 © (22.01.14 11:25) [253]
скорость записи лишних данных на диск значительно медленнее работы алгоритма по отбрасыванию лишнего из линковки
← →
Inovet © (2014-01-22 11:28) [255]> [253] Ega23 © (22.01.14 11:25)
> Надо линковать, тогда ещё быстрее будет.
Заодно винчестер поменять на какой-нибудь не старше хотя бы лет 10.
← →
Ega23 © (2014-01-22 11:38) [256]Удалено модератором
← →
DevilDevil © (2014-01-22 11:53) [257]Удалено модератором
Примечание: Выражения выбираем, не в пивной
← →
Ega23 © (2014-01-22 11:56) [258]Понятно. Не прочитал, в общем. Или прочитал, но не понял.
Ненаказуемо.
← →
имя (2014-01-22 11:59) [259]Удалено модератором
← →
DevilDevil © (2014-01-22 12:02) [260]> Ega23 © (22.01.14 11:56) [258]
Если мнение GunSmoker-а импонирует твоему нежеланию (и/или неумению) оптимизировать - это не значит, что вы правы.
По поводу актуальности он прав и я согласен. Но умный компилятор и скорость компиляции - актуальны по сей день. А ты об этом почему-то забываешь
← →
DevilDevil © (2014-01-22 12:04) [261]> Василий Иванов (22.01.14 11:59) [259]
> Выбери другой инструмент, делов-то?
Дак а я и выбираю. Программирую на Delphi 6 и 7
Только я болею за болею за развитие Delphi и мне не безразличен сабж. Просто хочется, чтобы кроме развития охвата платформ, компилятору прибавилось бы ещё и ума, а скорость компиляции ещё бы сократилась, в том числе и для C++Builder, а то там вообще ахтунг (с той же Visual Studio сравнивая)
← →
Ega23 © (2014-01-22 12:19) [262]Цена на 1 байт дискового пространства, а также оперативной памяти, за последние 20 лет упала порядков так на 6.
Вот, собственно, и всё.
← →
Игорь Шевченко © (2014-01-22 12:22) [263]http://russian.joelonsoftware.com/Articles/StrategyLetterIV.html
← →
DevilDevil © (2014-01-22 12:25) [264][257]
← →
Плохиш © (2014-01-22 13:35) [265]
> Только я болею за болею за развитие Delphi и мне не безразличен
> сабж.
Ещë один кухонный болельщик? Предложи производителю свои услуги по создонию сверкрутой среды разработки, а то они реально не справляются. То объявляют баги как desined и закрывают, то просто меняют текст исключения и то же баг объявляют закрытым.
← →
Kerk © (2014-01-22 13:52) [266]Если поставить себя на место менеджеров Embarcadero и представить, что есть свободные N человеко-часов для работ над компилятором - что же сделать:
1) исправить часть известных багов;
2) добавить больше функционала;
3) немного сократить размер exe.
Даже не знаю, чего бы я выбрал...
Если серьезно, то я отлично понимаю тех, кто хочет увидеть пофикшенные баги, более краткий синтаксис лямбд или вывод типов, но какие-то жалкие мегабайты... Да ну не серьезно это.
← →
Ega23 © (2014-01-22 14:04) [267]Если они наконец-то ErrorInside нормально сделают и Find Declaration - это будет гораздо бОльший успех и выгода во времени, чем мистические секунды и мегабайты.
← →
DevilDevil © (2014-01-22 14:11) [268]> Kerk © (22.01.14 13:52) [266]
> Ega23 © (22.01.14 14:04) [267]
Согласен
Только если сделать компилятор умным - к нему будут серьёзнее относиться - чаще закупать - денег будет больше - тем подобной этой не будет.
Сейчас есть поддержка Android и iOS. А толк?
Все как программили под Eclipse и XCode - так и программят
С чего бы это, да ?
← →
vuk © (2014-01-22 14:17) [269]to DevilDevil © (22.01.14 14:11) [268]:
> С чего бы это, да ?
Попробую угадать. Размер исполняемых модулей и только. Это единственная проблема, разумеется. :))
← →
Kerk © (2014-01-22 14:21) [270]Да, если бы вместо поддержки Android и iOS, уменьшили бы размер exe-шников, то все бы сейчас на Delphi писали, а не под Eclipse и XCode. Даже и не поспоришь.
Обсуждать, почему все срочно не пересели на средство разработки, которое появилось всего-то несколько месяцев назад, я на полном серьезе, пожалуй, не готов.
← →
jumping jack (2014-01-22 14:25) [271]не думаю, что новый компилятор стал медленнее старого или ухудшилась его способность выбрасывать лишнее при линковке - просто и VCL разжирел, и опции по умолчанию изменились
но поскольку DevilDevil вроде бы VCL доволен, а не доволен только FMX
и энтузиазма у него полно, то как бы напрашивается идея взять ему флаг в свои руки да и сделать свой собственный виджетсет, примерно так же отличающийся от FMX, как KOL от VCL (в сторону легкости и скорости)
ну, если свой виджетсет - слишком сложно, можно подумать об утилите или визарде, берущей весь исходный код FMX и копирующей её в папку проекта с должной обработкой (лучше в виде вставки кучи $IFDEF), позволяющей скомпилировать всё в супероблегченном виде (без RTTI, а, если можно, даже меняя virtual-методы на static)
← →
DevilDevil © (2014-01-22 14:26) [272]Не угадал
Основная проблема в том, что Delphi и C++Builder под девайсы не воспринимают всерьёз.
А происходит это уже по целому ряду причин
Баги FMX, медленная компиляция (билдер), низкое качество генерируемого под винду кода (ярлык, который закреплялся на протяжении уже не первого жесятка лет), тупой компилятор, плохой маркетинг, завышенная цена, огромный размер бинарного файла.
Зачем делать ставку на туфту если можно делать ставку на зарекомендовавшиеся себя решения? Вот и не делают. Размер бинарника - это всего лишь одно из проявлений низкокачественного компилятора и архитектуры, что в конечном счёте влияет на низкую популярность продукта
← →
jumping jack (2014-01-22 14:29) [273]и, конечно, с переводом DFM в код (эта утилита/визард)
← →
DevilDevil © (2014-01-22 14:33) [274]> которое появилось всего-то несколько месяцев назад
XE2 появился в 2011 году
бинарники под девайсы генерятся через LLVM. Как и в XCode кстати
FM вообще хрен знает сколько лет, раньше она по другому называлась
> Да, если бы вместо поддержки Android и iOS, уменьшили бы
> размер exe-шников, то все бы сейчас на Delphi писали, а
> не под Eclipse и XCode. Даже и не поспоришь.
давай мы перестанем устраивать детский сад и придумывать мессейджи, на которые я не намекал
по поводу размера, поддержки устройств и RTTI я тебе всё пояснил, причём несколько раз. Я не думаю, что такому взрослому человеку как ты, здесь может быть что-то не понятно
← →
vuk © (2014-01-22 14:34) [275]to DevilDevil © (22.01.14 14:26) [272]:
> А происходит это уже по целому ряду причин
От то-то же! Размер даже в приведенном списке, где-то на последнем месте. А в самом начале - нечто другое.
> Размер бинарника - это всего лишь одно из проявлений низкокачественного
> компилятора и архитектуры, что в конечном счёте влияет на
> низкую популярность продукта
Реквестирую список компонентных архитектур, приводящих к маленькому размеру бинарника! :)
← →
Kerk © (2014-01-22 14:36) [276]
> DevilDevil © (22.01.14 14:33) [274]
>
> > которое появилось всего-то несколько месяцев назад
>
> XE2 появился в 2011 году
> бинарники под девайсы генерятся через LLVM. Как и в XCode кстати
> FM вообще хрен знает сколько лет, раньше она по другому называлась
Поддержка iOS появилась в прошлом году в апреле, поддержка Android в прошлом году в сентябре. Всего-лишь год назад никаких iOS/Android в Delphi не было и следа. Я не думаю, что Delphi когда-нибудь станет популярнее, чем родные средства разработки для этих платформ, но все равно ждать хоть каких-то успехов на этом поприще еще слишком рано.
← →
DevilDevil © (2014-01-22 14:39) [277]> но поскольку DevilDevil вроде бы VCL доволен, а не доволен
> только FMX
Конкретно я не доволен и VCL в новых версиях. Всё то же время компиляции и размер бинарника. А почему это происходит - из-за дженериков, неймспейсов, инлайнов, RTTI или ещё какой билиберды - я уже не знаю. Я знаю, что можно сделать и быстрее и компактнее - было бы желание.
> и энтузиазма у него полно, то как бы напрашивается идея
> взять ему флаг в свои руки да и сделать свой собственный
> виджетсет, примерно так же отличающийся от FMX, как KOL
> от VCL (в сторону легкости и скорости)
энтузиазма полно. Только он целиком и полностью уходит на свои проекты. Его даже слишком мало :)
Delphi-компилятор я один не напишу :) А добавлять виджетсет типа KOL тоже не вижу смысла :)
← →
имя (2014-01-22 14:43) [278]Удалено модератором
Примечание: Достал
← →
DevilDevil © (2014-01-22 14:44) [279]> Поддержка iOS появилась в прошлом году в апреле
http://ru.wikipedia.org/wiki/Delphi_(%D1%81%D1%80%D0%B5%D0%B4%D0%B0_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8)#Delphi_XE2
← →
Ega23 © (2014-01-22 14:48) [280]Вроде и лет не двадцать.
Странно это всё.
← →
DevilDevil © (2014-01-22 14:50) [281]Вот и я про то
Странно, что не понимаете элементарнейших вещей
← →
Ega23 © (2014-01-22 14:52) [282]
> Странно, что не понимаете элементарнейших вещей
Я сейчас тебе аналогию приведу. Ты сейчас утверждаешь, что АК хуже М-16 из-за того, что та на дистанции в 300-500 метров несколько кучнее очередями стреляет.
И чо?
← →
Kerk © (2014-01-22 14:56) [283]
> DevilDevil © (22.01.14 14:44) [279]
>
> > Поддержка iOS появилась в прошлом году в апреле
>
> http://ru.wikipedia.org/wiki/Delphi_(%D1%81%D1%80%D0%B5%D0%B4%D0%B0_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8)#Delphi_XE2
А ты сам пробовал? В XE2 поддержка iOS и OSX была сделана с компиляцией через FreePascal, да так удачно, что из XE3 эту поддержку выбросили и вернули только в XE4 в полностью переработанном виде. Из EMBT даже людей уволили, которые руководили поддержкой устройств Эппла в XE2, настолько провально все получилось.
← →
DevilDevil © (2014-01-22 14:57) [284]Давай я тебе другую аналогию приведу
Я говорю "здоровым и богатым быть лучше, чем бедным и больным". А вы начинаете говорить "бедным быть не так уж и плохо, кому нужны эти деньги". Или "да все люди немного больные, зачем стремиться быть здоровым". Или вообще "лучше быть здоровым и бедным, чем богатым и бедным".
← →
Kerk © (2014-01-22 15:01) [285]
> DevilDevil © (22.01.14 14:57) [284]
Нет, тебе говорят, что в ситуации, когда "у меня 100 рублей и я могу купить либо пирожок, либо билет на автобус", рассуждать о том, что 200 рублей - это лучше, чем 100 рублей, бессмысленно. И так всем понятно, что лучше, но толку-то? В реальности ты либо поедешь голодным, либо сытый пойдешь пешком. Потому что у тебя в кармане именно 100 рублей, а не 200.
← →
DevilDevil © (2014-01-22 15:01) [286]> Kerk © (22.01.14 14:56) [283]
Я за расширение списка поддерживаемых платформ
Я за FMX как таковую
Это действительно верный путь развития.
Меня смущает время компиляции и качество/размер генерируемого кода
Во-первых, потому что меня бесит время компиляции, а новые возможности особо не нужны
Во-вторых, потому что это негативно влияет на рейтинг RAD Studio
Как ты понимаешь, размер Android-приложений существенно не уменьшится, если не отказаться от твоих любимых RTTI где надо и где не надо
← →
vuk © (2014-01-22 15:05) [287]to DevilDevil © (22.01.14 15:01) [286]:
> если не отказаться от твоих любимых RTTI где надо и где
> не надо
Отказаться можно только вместе с отказом от компонентной архитектуры.
← →
DevilDevil © (2014-01-22 15:07) [288]Удалено модератором
← →
vuk © (2014-01-22 15:09) [289]Удалено модератором
← →
DevilDevil © (2014-01-22 15:11) [290]Удалено модератором
← →
DevilDevil © (2014-01-22 15:12) [291]Удалено модератором
← →
имя (2014-01-22 15:12) [292]Удалено модератором
← →
Ega23 © (2014-01-22 15:14) [293]Удалено модератором
← →
Игорь Шевченко © (2014-01-22 15:26) [294]Рекомендую придерживаться конструктивного направления в дискуссии :)
← →
vuk © (2014-01-22 15:29) [295]to DevilDevil © (22.01.14 15:11) [290]:
> А почему ты не реквистируешь точное время рождения Иисуса
> Христа?
Могу. А надо? :)
> Что вообще в твоём понимании "компонентная архитектура"?
Компонентная архитектура ПО как минимум позволяет собирать функциональность приложения из неких готовых "кубиков" - компонентов. Компонеты при этом являются более-менее независимыми и слабо связанными программными блоками. Обычно компонентная архитектура подразумевает также монолитность компонентов и различные способы интроспекции.
> Ты вообще понимаешь, что такое линкер, как он убирает лишнее,
> что попадает в RTTI, чем отличается design-time bpl от
> exe ?
Хто? Я-то? Конечно, же не понимаю. Куда уж мне, деревне сиволапой! :))
← →
DevilDevil © (2014-01-22 15:36) [296]> vuk © (22.01.14 15:29) [295]
> Хто? Я-то? Конечно, же не понимаю. Куда уж мне, деревне
> сиволапой! :))
просто рассуждения какие-то... как будто не знаешь
странно это
> Компонентная архитектура ПО...
Вопрос тебе на засыпку. Не знаю, чё там в Visual Studio сейчас... Но когда я пробовал её в последний раз - там был MFC.
Так вот. MFC по твоему - это компонентная архитектура или нет?
И как по твоему они обходятся без RTTI?
← →
Пит (2014-01-22 15:39) [297]как обсуждали в дельфи 10 лет назад размер EXE"шника и почему он стал на 100кбайт больше в следующей версии, так и обсуждают )))
← →
vuk © (2014-01-22 15:43) [298]to DevilDevil © (22.01.14 15:36) [296]:
> MFC по твоему - это компонентная архитектура или нет?
Все, что я видел относительно MFC предполагает, что эта библиотека - не компонентная. Но при этом любая архитектура, основанная на dll - компонентная.
← →
DevilDevil © (2014-01-22 15:50) [299]исходя из этого
http://ru.wikipedia.org/wiki/Microsoft_Foundation_Classes
вроде как компонентная тоже
по крайней мере я создавал формы, таскал на них компоненты, а потом всё это запускалось. Опять таки в вики написано, что MFC это конкурент VCL. И они блин как-то обходятся без RTTI :)
Okey.
Теперь скажи. Что тебя смущает. Что в твоём понимании противоречащего произойдёт, если внутри exe published свойства не будут в RTTI?
← →
DVM © (2014-01-22 15:54) [300]
> DevilDevil © (22.01.14 15:50) [299]
> по крайней мере я создавал формы, таскал на них компоненты,
> а потом всё это запускалось. Опять таки в вики написано,
> что MFC это конкурент VCL.
Ты ничего не путаешь? Что ты там таскал то в MFC?
← →
имя (2014-01-22 15:56) [301]Удалено модератором
← →
DevilDevil © (2014-01-22 15:56) [302]Ну кнопки там, эдиты
У меня ещё дома есть книжка по MFC. Могу посмотреть
Правда кроме компонентов там были ещё всякие битмапы, файлы, etc.
← →
имя (2014-01-22 15:56) [303]Удалено модератором
← →
DevilDevil © (2014-01-22 15:57) [304]Удалено модератором
← →
DVM © (2014-01-22 16:02) [305]
> DevilDevil © (22.01.14 15:56) [302]
Там только диалоговые окна можно редактировать в стиле Delphi. Как ресурсы.
Но это я не назвал бы компонентами. Собственно такой вариант создания и редактирования диалоговых окон он и в делфи возможен.
← →
vuk © (2014-01-22 16:04) [306]
> исходя из этого
Если исходить из этого, то там даже слова "компонент" не нашлось. И, насколько я знаю, Microsoft библиотеку никогда не позиционировала, как компонентную.
>
> Опять таки в вики написано, что MFC это конкурент VCL.
Из того, что одно является конкурентом другого, никак не следует компонентность. Также, то, что библиотека может использовать, например, компоненты COM, не делает архитектуру библиотеки компонентной.
> Что в твоём понимании противоречащего произойдёт, если внутри
> exe published свойства не будут в RTTI?
Компонентная модель подразумевает монолитность и интроспекцию. В VCL эти вещи взаимосвязаны и могут использоваться не только механизмами загрузки форм, но и прочими механизмами, связанными с сериализацией. Соответственно, как только мы начинаем выкидывать код, который, казалось бы, не работает, может внезапно оказаться, что он станет нужен (ну вот взял я, допустим, и построил компонент, который свойства других компонентов из некоего хранилища подгружает). И это только если действовать тупо в лоб. Еще возможна куча всяких заморочек, связанных с регистрацией классов и динамическим созданием экземпляров.
← →
Inovet © (2014-01-22 16:06) [307]> [300] DVM © (22.01.14 15:54)
> Что ты там таскал то в MFC?
В визуальном редакторе ресурсов, видимо, координаты менял.
← →
Inovet © (2014-01-22 16:08) [308]> [261] DevilDevil © (22.01.14 12:04)
> а скорость компиляции ещё бы сократилась, в том числе и
> для C++Builder, а то там вообще ахтунг (с той же Visual
> Studio сравнивая)
Как такое возможно в Си++? Ну есть там для этой цели прекомпилируемые заголовки, хорошо сокращают время, а что ещё?
← →
DevilDevil © (2014-01-22 16:17) [309]> vuk © (22.01.14 16:04) [306]
> Компонентная модель подразумевает монолитность и интроспекцию.
Во-первых, ты это это у какого-то умного дядьки прочитал или сам придумал?
Про "блочность" я согласен
Во-вторых, компонентная модель никак не подразумевает под собой сериализацию или RTTI, к чему ты так отчаянно клонишь
В-третьих, design-time пакеты редко совпадают байт-в-байт с exe :)
Можешь ради интереса заюзать такие модули например как DesignIntf, DesignEditors, ToolsApi, ColnEdit. В то время как почти каждый серьёзный пакет визуальных компонентов данные модули содержат.
Run-time это run-time. Это и есть конечный продукт разработчиков ПО. Design-time это дополнительная приблуда, позволяющая удобно настроить часть свойств в IDE. Тот факт, что в RAD Studio две эти вещи близки - совсем не означают, что они идентичны. И тем более не означают, что обязаны быть идентичны.
Надеюсь объяснил доступно
← →
имя (2014-01-22 16:18) [310]Удалено модератором
← →
DevilDevil © (2014-01-22 16:18) [311]> Как такое возможно в Си++? Ну есть там для этой цели прекомпилируемые
> заголовки, хорошо сокращают время, а что ещё?
Слово божественное, молитвы, привороты
Очевидно же
← →
vuk © (2014-01-22 16:49) [312]
> Во-первых, ты это это у какого-то умного дядьки прочитал или сам придумал?
Что, имеет значение только то, что "у дядьки прочитал"? :) А так, вообще, эти вещи следуют из того, что компонент может быть использован в разных местах разными способами и потому должен содержать все, что относится ко всем этим способам использования и предоставлять клиенту некую информацию, как минимум для того, чтобы он мог понимать с кем имеет дело.
> Во-вторых, компонентная модель никак не подразумевает под
> собой сериализацию или RTTI, к чему ты так отчаянно клонишь
Я этого нигде не писал. Я писал, что в VCL компонеты подразумевают использование сериализации. Ну да, RTTI - это один из способов поддержки сериализации (но не только этого). Есть, конечно, и другой способ, когда RTTI не нужно - сериализацию можно делать полностью руками.
> В-третьих, design-time пакеты редко совпадают байт-в-байт
> с exe :)
Ясен пень, там находится код, который в рантайме не нужен с вероятностью 100% - редакторы компонентов, свойств и т.д. Это пакеты поддержки среды разработки, к функционированию непосредственно компонентов отношения не имеющие.
to DevilDevil © (22.01.14 16:18) [311]:
> Слово божественное, молитвы, привороты
И два часа компиляции, натурально. :)
← →
DevilDevil © (2014-01-22 16:56) [313]> vuk © (22.01.14 16:49) [312]
Тогда почему ты решил, что компоненты, спроектированные без дельфийского RTTI-доступа к свойствам перестают быть компонентами или как ты там выразился... "противоречат компонентной модели"?
И как ты тогда расцениваешь тот факт, что в design-time bpl линкуется не весь код, который можно заюзать из ран-тайма? Например множество статических функций. Которые можно использовать из ран-тайм, но их вызов не производится при смене или взятии значения свойств.
← →
Василий Иванов (2014-01-22 17:01) [314]извините, а RTTI сильно много размер увеличивает?
← →
DevilDevil © (2014-01-22 17:01) [315]> И два часа компиляции, натурально. :)
Вообще я вижу дофига способов увеличить скорости компиляции С++ проектов. Но с вами я их не буду, по причинам, озвучивать которые тоже не буду, дабы никого не обидеть.
Скажу лишь, что наиболее простое решение - это построить компилятор на основе Clang, который сильно заточен под итеративную разработку - что достаточно сильно увеличивает скорость компиляции в реальных условиях. Кроме того бинарники там генерятся через LLVM, что даст значительно лучшее качество кода по сравнению с дефотлным компилятором C++Builder.
← →
DevilDevil © (2014-01-22 17:03) [316]> Василий Иванов (22.01.14 17:01) [314]
> извините, а RTTI сильно много размер увеличивает?
VCL проект в Delphi6 занимает порядка 350Кб
VCL проект в Delphi XE занимает порядка 10Мб, если ничего не путаю
← →
DevilDevil © (2014-01-22 17:06) [317]> Василий Иванов (22.01.14 17:01) [314]
а если доработать линковку virtua/dinamic и сменить политику dfm/published - то вообще будет порядка 200кб
← →
vuk © (2014-01-22 17:11) [318]to DevilDevil © (22.01.14 16:56) [313]:
> Тогда почему ты решил, что компоненты, спроектированные
> без дельфийского RTTI-доступа к свойствам перестают быть
> компонентами или как ты там выразился... "противоречат компонентной
> модели"?
Они не вписываются в компонентную модель VCL. То есть это должен быть какой-то свой фреймфорк, с блекджеком и шлюхами. И да, расписывание сериализации в ручную не уменьшит размер исполняемого модуля.
> И как ты тогда расцениваешь тот факт, что в design-time
> bpl линкуется не весь код, который можно заюзать из ран-
> тайма?
В Designtime пакеты обычно включаются вообще другие наборы модулей - те которые нужны на этапе проектирования. Именно для того, чтобы они не лезли туда, куда не надо - в рантайм.
← →
Ega23 © (2014-01-22 17:14) [319]
> VCL проект в Delphi XE занимает порядка 10Мб, если ничего не путаю
2.35 ХЕ4
← →
vuk © (2014-01-22 17:15) [320]to DevilDevil © (22.01.14 17:03) [316]:
> VCL проект в Delphi6 занимает порядка 350КбVCL проект в
> Delphi XE занимает порядка 10Мб, если ничего не путаю
Путаете, определенно. Сейчас посмотрел, махонький проект, но сс cxGrid, ExpressBars и кой-каким своим фреймворком. Три с половиной мега.
← →
Игорь Шевченко © (2014-01-22 17:25) [321]Проект с пустой формой в XE5 без отладочной информации - 2,104,320 байт
Проект с пустой формой в XE5 с отладочной информацией - 10,795,179 байт
← →
DevilDevil © (2014-01-22 17:31) [322]> vuk © (22.01.14 17:11) [318]
> Они не вписываются в компонентную модель VCL. То есть это
> должен быть какой-то свой фреймфорк, с блекджеком и шлюхами.
Если сейчас VCL использует для прогрузки свойств RTTI - это совсем не значит, что всегда будет использовать RTTI, и тем более не значит, что всегда должна будет использовать RTTI.
> И да, расписывание сериализации в ручную не уменьшит размер
> исполняемого модуля.
Ты используешь сильно общие термины, не обозначая область применения. Если мы говорим о замене dfm на инициализирующий код и отказе от RTTI в местах, где разработчик явно не укажет использовать RTTI - то разумеется размер бинарника сократится. Что в данном случае подразумеваешь ты - видимо известно только тебе
← →
DevilDevil © (2014-01-22 17:32) [323]> Игорь Шевченко © (22.01.14 17:25) [321]
а зачем в exe заливать 8Мб отладочной информации ?
← →
vuk © (2014-01-22 17:52) [324]to DevilDevil © (22.01.14 17:31) [322]:
> Если сейчас VCL использует для прогрузки свойств RTTI -
> это совсем не значит, что всегда будет использовать RTTI,
> и тем более не значит, что всегда должна будет использовать
> RTTI.
Очевидно, что это будет уже не VCL, а что-то другое. :) VCL же, я думаю, останется такой же, как и была.
← →
DevilDevil © (2014-01-22 17:56) [325]> vuk © (22.01.14 17:52) [324]
> Очевидно, что это будет уже не VCL, а что-то другое. :)
> VCL же, я думаю, останется такой же, как и была.
http://ru.wikipedia.org/wiki/Visual_Component_Library
Здесь пишут, что VCL - это "Библиоте́ка визуа́льных компоне́нтов", и ни слова про RTTI
Говорить что VCL это RTTI-прогрузка свойств, а RTTI-прогрузка свойств это VCL - да не забанят меня модераторы, глупо.
← →
vuk © (2014-01-22 17:58) [326]to DevilDevil © (22.01.14 17:56) [325]:
> и ни слова про RTTI
Ну, займись, выкини оттуда RTTI, посмотри, что получится. Насколько оно будет визуально и компонентно. :)
← →
имя (2014-01-22 18:01) [327]Удалено модератором
← →
vuk © (2014-01-22 18:03) [328]Удалено модератором
← →
DevilDevil © (2014-01-22 18:04) [329]> vuk © (22.01.14 18:03) [328]
Я не считаю, что всякую мелочь нужно доказывать
Тем более человеку, который имеет статус "Мастера"
← →
vuk © (2014-01-22 18:07) [330]Мне почему-то не кажется, что это мелочь. Но раз доказательством теорий заниматься желания нет, то так пусть и будет тем, что есть - трепом.
← →
DevilDevil © (2014-01-22 18:08) [331]Okey, иду тебе на встречу
Докажи, что прогрузить свойства без VCL невозможно - а я докажу, что каждый приведённый тобой пример достаточно легко обходится.
← →
DevilDevil © (2014-01-22 18:09) [332]* без RTTI
← →
vuk © (2014-01-22 18:11) [333]Пример приводился. Компонент, загружающий свойства других компонентов из некоего хранилища. Список свойств и может поступать извне.
← →
vuk © (2014-01-22 18:11) [334]Список свойств настраиваемый и может поступать извне.
← →
DevilDevil © (2014-01-22 18:18) [335]> vuk ©
В данном примере тебе сериализация, ничего общего не имеющая с вопросом прогрузки свойств "из dfm". Сериализацию делаешь вручную или выставляя опции компилятора генерировать RTTI по конкретным компонентам. Сериализация нужна не всем и не часто. Это совсем не означает, что всё остальное мировое сообщество обязано таскать в своих приложениях 10Мб ненужного хлама.
← →
DevilDevil © (2014-01-22 18:19) [336]* нужна
← →
vuk © (2014-01-22 18:24) [337]to DevilDevil © (22.01.14 18:18) [335]:
> В данном примере тебе сериализация, ничего общего не имеющая
> с вопросом прогрузки свойств "из dfm"
Механизм в основе один и тот же - RTTI. Без этого механизма автоматизированная работа таких вещей нереальна.
> Сериализацию делаешь вручную или выставляя опции компилятора
> генерировать RTTI по конкретным компонентам.
Ключевая особенность - компонент не знает заранее, что ему придется загружать. Надо генерить по всем. И какая разница тогда?
> Сериализация нужна не всем и не часто.
Кому как. У меня такой компонент живет в базовом фрейме приложения. :)
← →
vuk © (2014-01-22 18:27) [338]Да, насчет хлама. Хлам в исполняемом модуле, главным образом тогда, когда основное занятие - развлечение с компиляцией пустого проекта. Чем больше приложение делает много чего нужного, тем меньше остается хлама. И тем меньше обращаешь на него внимание. Мировое сообщество, судя по приведенным тут ссылкам, делает примерно так же. Такие дела.
← →
DevilDevil © (2014-01-22 18:27) [339]> vuk © (22.01.14 18:24) [337]
> Механизм в основе один и тот же - RTTI. Без этого механизма
> автоматизированная работа таких вещей нереальна.
Сейчас
Сейчас прогрузка свойств из dfm осуществляется через сериализацию
Но это совсем не означает, что прогрузка свойств обязана производиться через сериализацию
> Кому как. У меня такой компонент живет в базовом фрейме
> приложения. :)
Тебе нужна - ты и используй
Зачем ты пихаешь сериализацию тому, кому она нафиг не нужна?
← →
Василий Иванов (2014-01-22 18:29) [340]
> DevilDevil © (22.01.14 17:03) [316]
>
> > Василий Иванов (22.01.14 17:01) [314]
> > извините, а RTTI сильно много размер увеличивает?
>
> VCL проект в Delphi6 занимает порядка 350Кб
> VCL проект в Delphi XE занимает порядка 10Мб, если ничего
> не путаю
Да, но какой вклад в размер здесь дает RTTI? И вообще, что ты под этим термином понимаешь? Все методы и прочее, что, возможно(скорее всего), никогда не будут вызваны в расчет не принимаются - спорить об очевидном сейчас нет настроения.
← →
DevilDevil © (2014-01-22 18:29) [341]> vuk © (22.01.14 18:27) [338]
> Да, насчет хлама. Хлам в исполняемом модуле, главным образом
> тогда, когда основное занятие - развлечение с компиляцией
> пустого проекта. Чем больше приложение делает много чего
> нужного, тем меньше остается хлама. И тем меньше обращаешь
> на него внимание. Мировое сообщество, судя по приведенным
> тут ссылкам, делает примерно так же. Такие дела.
Мировое сообщество отказывается от Delphi и C++Builder. "Несмотря на то", что сериализация всего существует уже не первый год
Вот такие дела
← →
DevilDevil © (2014-01-22 18:30) [342]> Василий Иванов (22.01.14 18:29) [340]
> Да, но какой вклад в размер здесь дает RTTI? И вообще, что
> ты под этим термином понимаешь? Все методы и прочее, что,
> возможно(скорее всего), никогда не будут вызваны в расчет
> не принимаются - спорить об очевидном сейчас нет настроения.
А у тебя у самого есть какие-нибудь догадки, почему раньше VCL-приложение весило 350кб, а сейчас даже пусть 2Мб ?
← →
Юрий Зотов © (2014-01-22 18:32) [343]Удалено модератором
← →
vuk © (2014-01-22 18:34) [344]to DevilDevil © (22.01.14 18:29) [341]:
> Мировое сообщество отказывается от Delphi и C++Builder.
> "Несмотря на то", что сериализация всего существует уже
> не первый годВот такие дела
Зато оно же во всю использует, например, дотнет. Про размер этого компонентного фреймворка, надеюсь, напоминать не надо?
← →
имя (2014-01-22 18:35) [345]Удалено модератором
← →
имя (2014-01-22 18:36) [346]Удалено модератором
← →
Василий Иванов (2014-01-22 18:37) [347]
> DevilDevil © (22.01.14 18:30) [342]
> А у тебя у самого есть какие-нибудь догадки, почему раньше
> VCL-приложение весило 350кб, а сейчас даже пусть 2Мб ?
методы там всякие. Это тоже к RTTI относится?
← →
DevilDevil © (2014-01-22 18:40) [348]> методы там всякие. Это тоже к RTTI относится?
если свойство или метод попадает в RTTI - то связанный с ним код попадает в линкер
раньше это касалось только published-свойств наследников TPersistent. Сейчас это касается всего. Поэтому разница минимум в 6 раз
← →
vuk © (2014-01-22 18:40) [349]Удалено модератором
← →
имя (2014-01-22 18:42) [350]Удалено модератором
← →
Василий Иванов (2014-01-22 18:42) [351]Удалено модератором
← →
vuk © (2014-01-22 18:44) [352]Удалено модератором
← →
Василий Иванов (2014-01-22 18:46) [353]Удалено модератором
← →
Юрий Зотов © (2014-01-22 18:49) [354]Удалено модератором
← →
имя (2014-01-22 19:04) [355]Удалено модератором
← →
Плохиш © (2014-01-22 19:10) [356]Ну всё, опять ветка за вас краснеет.
← →
Ega23 © (2014-01-22 19:17) [357]
> а зачем в exe заливать 8Мб отладочной информации ?
Ну как... Есть Release, есть Debug.
← →
DevilDevil © (2014-01-22 19:19) [358]> Ega23 © (22.01.14 19:17) [357]
Логика подсказывает, что отладочная информация нужна в дебагере, а не в exe. А с учётом того, что дебагер находится внутри IDE - логично держать эти 8мб в ОЗУ IDE.
← →
vuk © (2014-01-22 19:21) [359]Attach to process
← →
Ega23 © (2014-01-22 19:32) [360]
> Логика подсказывает, что отладочная информация нужна в дебагере,
> а не в exe. А с учётом того, что дебагер находится внутри
> IDE - логично держать эти 8мб в ОЗУ IDE.
Логика подсказывает, что процесс тестирования приложения включает в себя далеко не только запуски под отладчиком. Запуск под отладчиком - это поиск бага. Но сначала надо знать, что этот баг - есть.
← →
Rouse_ © (2014-01-22 20:10) [361]
> DevilDevil © (22.01.14 19:19) [358]
> > Ega23 © (22.01.14 19:17) [357]
>
> Логика подсказывает, что отладочная информация нужна в дебагере,
> а не в exe. А с учётом того, что дебагер находится внутри
> IDE - логично держать эти 8мб в ОЗУ IDE.
Здесь у тебя причинно-следственная часть сбоит. IDE и дебагер - разнесены, поэтому IDE (как обычной гуевой обертке, отладочная информация вообще нафиг не нужна), а с учетом того, что отладчиков много, и мы каждым из них можем воспользоваться - была придумана такая вещь, как хранение дебаг инфы как внутрях исполняемого модуля, так и во внешних файлах, причем ввиде достаточно большого количества документированных форматов, от RTD до банального MAP (жаль PDB все еще не прикрутят).
ЗЫ: и кстати, а что такое "ОЗУ IDE"? :)
← →
clickmaker © (2014-01-22 20:22) [362]> что такое "ОЗУ IDE"?
сурьезные программеры юзают сурьезные IDE со своими ПЗУ, ОЗУ, ИБП...
← →
DevilDevil © (2014-01-22 20:36) [363]Ребят, вы сейчас говорите о том, как просто
Я говорю о том как нужно
Может вам и нравится медленное громоздкое ПО
Вы можете находить оправдания почему то или иное решение применимо
И вы по своему правы, почему то или иное решение применимо. Только вот у производителей отечественного авто тоже были оправдания почему не делать качественные модернизации. И итог всем известен. "Волгу" к примеру в моём родном городе больше не выпускают
← →
имя (2014-01-22 21:08) [364]Удалено модератором
← →
Плохиш © (2014-01-22 21:09) [365]
> Только вот у производителей отечественного авто тоже были
> оправдания почему не делать качественные модернизации.
Деланье модернизаций не только от желания производителей зависит, это так к сведению. Кстати и желания там даже не в первом десятке предпосылок находятся.
← →
имя (2014-01-22 21:48) [366]Удалено модератором
← →
Ega23 © (2014-01-22 21:52) [367]
> Только вот у производителей отечественного авто тоже были
> оправдания почему не делать качественные модернизации.
Видишь ли. Понятие "качественная модернизация" - оно расплывчатое. Ты никогда не сможешь сделать автомобиль, который будет разгоняться до ста за 5 секунд, держать на трассе 150 при расходе топлива в 10 литров, перевозить отделение бойцов, 1.5 тонны груза, иметь 30 мм автоматическую пушку, выдерживать попадание 152мм фугаса, иметь возможность преодоления водных преград глубиной до 15 метров, разгоняться до 60 по тундре и менять масло после ста тыщь пробега. И всё это не дороже, чем за 800.000 рублей.
Определись уже.
← →
имя (2014-01-22 22:15) [368]Удалено модератором
← →
картман © (2014-01-22 22:18) [369]Удалено модератором
← →
DevilDevil © (2014-01-22 22:31) [370]Удалено модератором
Примечание: Ша за чушь?!!!
Страницы: 1 2 3 4 5 6 7 8 9
10 вся ветка
Форум: "Прочее";
Текущий архив: 2014.08.17;
Скачать: [xml.tar.bz2];
Память: 1.56 MB
Время: 0.014 c
