V1s1ter Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору           Обсуждаем новые возможности и баги   Просьба писать про Embarcadero RAD Studio XE5, XE6, XE7, XE8, 10.x (Seattle, Berlin,Tokyo)   По вопросам скачивания - Тема в Варезнике (lite-версии тут)   Вопросы по неюникодным версиям Delphi — шестая бумага   Бесплатные Компоненты и утилиты для Delphi/BCB/FreePascal/Lazarus   Коммерческие компоненты и утилиты для Delphi/BCB   Вопросы по компонентам для Delphi, C++ Builder разных версий   Новые языковые возможности, начиная с Delphi 2005 по XE4 — здесь, и New!здесь еще   Англоязычный официальный форум Embarcadero — здесь   Embarcadero Quality Central, веб интерфейс — здесь, новый Quality Portal тут   Программирование на Delphi — викиверситет   Другие ресурсы    Предыдущие бумаги        Вопросы ..XE4       Вопросы ..XE3     Вопросы ..XE2         Вопросы ..2009-XE     Вопросы ..<2009 / ч.5     Вопросы ..<2009 / ч.4         Вопросы ..<2009 / ч.3     Вопросы ..Delphi 2 / ч.2     Вопросы ..Delphi     Выключение встроенного эксперта Castalia  для XE8 (иногда помогает при вылетах и тормозах)     Полезные плагины(эксперты) Всего записей: 948 | Зарегистр. 06-02-2007 | Отправлено: 15:25 11-09-2013 | Исправлено: Komandor, 15:49 31-03-2024

landy Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Взгляни на SQL parser for VCL Вдогонку - вот еще один парсер структуры БД: Database Comparer VCL v 6.1 for Delphi, C++Builder Всего записей: 576 | Зарегистр. 17-01-2003 | Отправлено: 22:59 02-01-2015

mrUlugbek Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Привет!   Как и с помощью чего можно реализовать такую фичу аля 1С8 лукап список выбора   http://uploads.ru/A2Sia.png   При наборе символов в поле ввода, подключенному к справочнику по первым нескольким символам отображается лукап список с совпадающими элементами, при выборе из которого в поле копируется нужный элемент.   Спасибо.     Посмотри у Ehlib есть такой функционал не эта случайно     Ссылка     Всего записей: 879 | Зарегистр. 04-04-2011 | Отправлено: 11:00 03-01-2015

landy Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Судя по всему, сделано на ФМ. Эм, а что именно наводит тебя на такую мысль? Всего записей: 576 | Зарегистр. 17-01-2003 | Отправлено: 14:17 03-01-2015

AlekXL Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Судя по всему, сделано на ФМ. А мы всё надеемся и ждем чуда: что на FMX все же можно писать элегантный софт..   А может, ну его? Весь мир движется к "жрущему" и тормозному софту под флагами .NET и прочих скриптовых GC поделий. Давайте и мы будем говнокодить, только на Delphi/FMX. Ведь сложное приложение на далвике, и такое же приложение на FMX -- тормозить будет одинаково жестко, не так ли? Это только на простых у жабы преимущество.   ---   а кто пользовался "препроцессором" http://sourceforge.net/projects/dpp32/?source=typ_redirect Delphi? И есть ли подобные фишки еще? Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 21:31 04-01-2015 | Исправлено: AlekXL, 21:41 04-01-2015

kaz_av Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору AlekXL Цитата: Весь мир движется к "жрущему" и тормозному софту под флагами .NET и прочих скриптовых GC поделий. Все как раз наоборот У ведроида ART уже в новых версиях активирован по дефолту, у МС его аналог (или, если угодно, аналог ngen, в общем тот самый AOT вместо JIT) работает на стороне магазина приложений. Теперь байт-код служит лишь временным представлением программного кода от момента сборки до момента установки приложения, а дальше работает натив (индустрия таки вернулась к изначальной идее ). Теперь ведроидный SDK-софт мало чем будет отличаться в плане производительности от NDK-софта, и, возможно, необходимость в последнем со временем вообще отпадет.   Цитата: Давайте и мы будем говнокодить, только на Delphi/FMX Ждем саксесс стори от тебя. Всего записей: 439 | Зарегистр. 15-02-2006 | Отправлено: 22:15 04-01-2015

AlekXL Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору kaz_av Цитата: , а дальше работает натив (индустрия таки вернулась к изначальной идее ).     нет, не вернулась. Как ты не поймешь, дело вовсе не в интерпретации и джиттерах, а в ручном управлении памятью. А значит, нет возможности создавать специализированные высокоэффективные структуры данных(контейнеры) для критических по отн. к памяти  алгоритмических задач. Отсюда все растет, я считаю.     Ты не знаешь, когда будет освобожден неиспользуемый буфер.  Но когда это произойдет, то будет тормоз на весь пул потоков, без изъятий , то есть либо заикание интерфейса, либо что похуже.     Я видел сложный и объемный проект на шарпе, предназначенный для автотрейдинга на форекс-подобных биржах. Девелоперы(по уровню знаний программирования - любители, неспецы) жаловались на микрозадержки порядка 30мс, которые были для них критичны. Так вот, они не торговались, когда нужно было что-то с этим сделать... А сделать что-то весьма нелегко -- либо рефакторить всё, все явные и неявные выделения памяти, боксинг и т.д в цикле обработки и соседних нитях . Либо писать демона в отдельном контексте, и желательно, не на GC-платформе. -- ..Если бы в доднете была бы хотя бы возможность вручную аллоцировать память под структурный тип, или буфер, тогда еще ладно, но такой возможности нет. Да и сама идея достижимости, в отличие, скажем,  от подсчета ссылок, порочна.   Добавлено: Добавь сюда практически горизонтально-асимптотический тренд развития железа, по сравнению с как минимум линейным прогрессом алгоритмических решений, и увидишь не упадок парадигмы NDK, а "Возвращение Короля".   Может вернуться то время, когда нас удивляли одиночки, умещавшие шедевры в 48/128 килобайт "Cпекки" или "Коммодора", только вместо одиночек будут корпорации. Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 22:56 04-01-2015 | Исправлено: AlekXL, 23:17 04-01-2015

Alexey_Gawrilow Advanced Member Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору kaz_av Цитата: Теперь байт-код служит лишь временным представлением программного кода от момента сборки до момента установки приложения, а дальше работает натив (индустрия таки вернулась к изначальной идее  ).   Ну как вот не вспомнить Михаеля Франца с его Juice. Шикарная вещь. Единственный недостаток - "фатальный недостаток" Ну или так     Добавлено: AlekXL Цитата: препроцессором Цитата: И есть ли подобные фишки еще? DLangExtensions от Andreas Hausladen была крута. Имеется ввиду именно инженерное решение - Andreas безусловно крут.   http://www.devsuperpage.com/search/Articles.asp?ArtID=1143196   мертвое сейчас. Всего записей: 640 | Зарегистр. 08-09-2003 | Отправлено: 23:14 04-01-2015

AlekXL Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору друзья, а здесь есть кто-нибудь, кто бескорыстно коммиттит в развитие Delphi/FPC? Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 23:29 04-01-2015

AlekXL Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Об этом нужно говорить с цифрами в руках, т.е. делать многократное профилирование и выяснение действительно узких мест. Может статься, что GC окажется не при делах. Ну и ART несет некоторые изменения для GC.   Не надо ляля. Ручное управление памятью бесспорно быстрее и эффективнее GC, вопрос только - насколько? Чем сложнее приложение, чем больше оно требует ресурсов, тем менее приемлем GC. Знаете ли вы хотя бы один подобный проект, на платформе GC, у которого бы не было проблем с отзывчивостью или скоростью? Я - не знаю. Доходит до абсурда, тот же FF - у него вроде  GC, но не только медленный и заикается, так еще и память у него течет пропадая.   Цитата: Идея как раз красивая. Подсчет ссылок более проблематичен Чем?     Тем, чтобы необходимо следить за циркулярными референсами?     Цитата: слабые ссылки в глобальном списке это - рукалицо. С использованием слабых ссылок, мы уходим от проблемы утечки, но приходим к   нуль-референс угрозе, когда слабая ссылка ненароком не обнулилась. Лекарство хуже болезни.   Подсчет ссылок лишь подспорье для ручного управления памятью, а вовсе не средство для абстракции от этой задачи.   А решение для абстракции - именно достижимость. Интересно, много ли пройдет времени, когда они додумаются скомбинировать эти подходы: делать основную работу подсчетом сильных ссылок, а в фоне эвристиками на основании прекомпилированных данных статического анализа исходного кода, искать кольца -- алгоритмом достижимости либо зачетом ссылок в кольце (когда проверяется гипотеза, что удаление одной структуры влечет удаление всего кольца).         Добавлено: Цитата: У самой платформы скорее всего есть, на уровне шарпа возможно нет. Например FPC умеет компилировать под JVM - платформу с управляемой памятью и GC - и при этом работают низкоуровневые трюки с указателями и управлением памятью.   разумеется. Память - это ведь просто массив, только индексируется он не с нуля, как привыкли скобкокропатели. В рамках этого массива можно организовать менеджер кучи - задача популярная у нас, паскалистов. Проблема в том, что Шарп и Ява не дают возможности хранить нетривиальные типы в произвольных областях. Это вам не кресты, в которых можно как угодно переопределить оператор new.   Добавлено: Цитата:   А в Delphi можно коммитить? Конечно! Не в компилятор, конечно, но на самом деле туча возможностей, от препроцессинга кода до написания хороших базовых библиотек на замену FMX.   А можно просто написать хороший учебник по Delphi вот например   в статье викиверситета мой вклад больше половины. Мелочь, но если бы нас было 20-100 человек, учебник был бы быстро написан. Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 00:11 05-01-2015 | Исправлено: AlekXL, 00:30 05-01-2015

AlekXL Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Непосредственно идеей и механизмом разрешения. Просто и красиво Пузырьковая сортировка тоже проста и красива.   Цитата: Погугли кому свойственна категоричность суждений.   при чем тут гугл? Мы говорим о потенциале. Грамотное ручное управление лучше любого автомата, потому что человек умнее любого автомата, когда дело доходит до сложных проблем. Это аксиома. Цитата: я пользуюсь одним приложением под mono (Tomboy)   Цитата: нативный GoldenDict   ну это черрипикинг. Ты берешь хороший/лучший пример GC против плохого/худшего примера натива. А ты возьми лучший пример GC и лучший пример ручного управления. Догадываешься, каким будет результат? Вот об этом то я и говорю.   Цитата: В общем, с такой реализацией рассуждать о тормозах GC, это, мягко говоря, очень смело. мы говорим о концепциях и потенциале этих концепций, а не об особенностях реализации.   Причем, думается, даже в такой реализации, зануление конкретной ссылки остановит процесс на меньшее время, чем поиск недостижимых областей. Ибо в обоих случаях мы имеем блокировку, но  первая задача строго детерминирована по времени, тогда как вторая -- далеко не детерминирована.       Добавлено: Цитата: Вот и подумай, так ли порочна идея...   мало того, что GC снижает порог вхождения, разрешая небрежный код, так еще хороший код GC замедляет. Скрывает разницу. Кропателям это на руку, а гикам?   Добавлено: А еще GC порочен потому, что понимание его ущербности приходит слишком поздно, когда в проект уже вложено тысячи человеко-часов. Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 01:08 05-01-2015 | Исправлено: AlekXL, 01:09 05-01-2015

kaz_av Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору AlekXL Цитата: при чем тут гугл? Ладно, не хочешь гуглить... Категоричность суждений свойственна невеждам (с). Цитата: Это аксиома.   Только в твоей теории. Но по красоте теорий, теория GC не оставит камня на камне от твоей теории Операция выделения памяти для GC это изменение указателя и только, а это очень дешевая операция даже по сравнению с менеджерами памяти основанными на пулах. GC доступна статистика работы приложения, и он может подстраивать собственные эвристики для более качественного выполнения работы. У GC нет проблемы с циклическими ссылками и фрагментацией памяти. GC более cache friendly, чем подсчет ссылок. Это если говорить о теории. А на практике ты можешь запустить ProcessExplorer и посмотреть сколько времени в работе дотнет-приложения занимает работа GC - смешные цифры.   Цитата: Ты берешь хороший/лучший пример GC против плохого/худшего примера натива.   Я взял два самых обычных приложения из моего рабочего окружения.   Цитата: Догадываешься, каким будет результат? Предпочитаю не догадываться, а смотреть на реальный результат. А в реальности управляемые приложения работают хуже чем в теории, но ровно также хуже работают и нативные. Поэтому глупость спорить о красоте теорий я оставлю тебе, а сам буду говорить о практике.   Цитата: Причем, думается, даже в такой реализации, зануление конкретной ссылки остановит процесс на меньшее время, чем поиск недостижимых областей. Ибо в обоих случаях мы имеем блокировку, но  первая задача строго детерминирована по времени, тогда как вторая -- далеко не детерминирована.   Так ты не думай, ты проверь! Неверные предпосылки, они, как известно, ведут к неверным выводам. Ты в курсе, что GC может работать параллельно основным кодовым потокам и практически исключить появление пауз? А в курсе, что подсчет ссылок в дельфях, сделанный на основе вызова виртуальных (двойнойрукалица) методов адово замедляет работу приложения?   Цитата:   мало того, что GC снижает порог вхождения, разрешая небрежный код, так еще хороший код GC замедляет А ты, стало быть, за чистоту рядов ратуешь? Вообще говоря, на хороший код GC влияния не оказывает чуть менее чем совсем. Догадайся почему.   Цитата: А еще GC порочен потому, что понимание его ущербности приходит слишком поздно, когда в проект уже вложено тысячи человеко-часов. У двоечников считающих GC серебряной пулей. Всего записей: 439 | Зарегистр. 15-02-2006 | Отправлено: 11:01 05-01-2015 | Исправлено: kaz_av, 11:02 05-01-2015

SuPriTo Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Ручное управление памятью бесспорно быстрее и эффективнее GC, вопрос только - насколько? Чем сложнее приложение, чем больше оно требует ресурсов, тем менее приемлем GC. Сейчас делаю проект на C#. Пишу робота для торговли на бирже. И вот я уже задолбался с этим сборщиком мусора. Когда идет большой массив данных, постоянные тормоза. Плюс я использую внешнюю библиотеку и постоянно думаю, почистилась память или не почистилась. Но по ходу видимо не почистилась, а может еще какие-то ссылки есть. И это постоянно в каких-то терзаниях по поводу автоматической сборки мусора. Цитата: Проблема в том, что Шарп и Ява не дают возможности хранить нетривиальные типы в произвольных областях. Шарп дает возможность хранить данные в произвольных областях памяти. Но это не решает проблемы очистки памяти, а еще больше усложняет программирование. Если в делфи автоматически очищается память при обнулении ссылок. И этим вопросом можно управлять. То в GC это один большой вопрос и сделать это не так-то просто. В итоге для эффективной работы переписывать сборщик мусора для работы с большими данными. И в целом это тот еще геморрой. Цитата: Только в твоей теории. А если на практике, то все будет с точностью на оборот. И приходится транить большое кол-во часов на то, чтобы все это дело оптимизировать. А когда используешь сторонние библиотеки это превращается в целый кошмар, т.к. в сторонней библиотеке мало кто об этом задумывается. Цитата: А на практике ты можешь запустить ProcessExplorer и посмотреть сколько времени в работе дотнет-приложения занимает работа GC - смешные цифры.   Эти смешные цифры в неподходящее время могут быть совсем не смешными. Цитата: Ты в курсе, что GC может работать параллельно основным кодовым потокам и практически исключить появление пауз? Конечно он может, но от пауз не избавляет (особенно, когда данных на несколько сот мегабайт), видимо пока его самого не перепишешь (это мои предположения). GC помогает в только, когда много памяти.   Цитата: А сделать что-то весьма нелегко -- либо рефакторить всё, все явные и неявные выделения памяти, боксинг и т.д в цикле обработки и соседних нитях . Либо писать демона в отдельном контексте, и желательно, не на GC-платформе.   Вот это как раз на практике так и получается.   Всего записей: 1475 | Зарегистр. 24-03-2009 | Отправлено: 12:06 05-01-2015 | Исправлено: SuPriTo, 12:16 05-01-2015

SuPriTo Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Для натива тут вообще смерть - сторонний код есть потенциальный источник самых невероятных граблей.   Ой, ли. Для натива много всяких возможностей обойти грабли. Цитата: А чего, кстати, не на дельфях пишешь? На делфях пишу. Данный проект делаю по причине наличия подходящей библиотеки на C#, которая позволяет быстрее реализовать задуманное. Сейчас собираюсь переписать данную библиотеку под делфи со своей собственной спецификой. Цитата: Ну вот как раз такие разочарования в GC и случаются у людей считающих его серебряной пулей. Я не считаю его серебряной пулей, я его считаю некоторой проблемой, с которой приходится сталкиваться. Если в делфи или на си я просто выделил память, то я знаю, что эту память нужно очистить. Когда и где это мои личные проблемы от меня зависящие. В GC у меня вечный вопрос, а почистилась ли память или нет? А почистилась ли память во внутренних структурах библиотеки, т. к. она сложна и т. д. Ответ в делфи на этот вопрос решается одной строкой, а в GC это сбор и исследование статистики. И походу придумывание различных граблей для анализа статистики. Для простых приложений GC подходящая может очень подходящая штука. Но я привык работать так - выделил, почистил и забыл. А GC в этом смысле предлагает массу различных вариантов. Цитата: Так у GC есть несколько стратей работы,  тот же конкурентный GC избавляет от пауз ценой некоторого замедления процесса сборки.   Так вот это уже приходится в этом вопросе разбираться и тратить кучу времени на это. Как и что у него работает. И не факт, что он избавит от пауз, он еще и сожрет кучу памяти. Но тут вопрос тестирования и исследования. В делфи данный вопрос решается одной строкой.     Всего записей: 1475 | Зарегистр. 24-03-2009 | Отправлено: 12:54 05-01-2015 | Исправлено: SuPriTo, 12:55 05-01-2015

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Embarcadero RAD Studio

Переход по форумам  Закладки   » Компьютеры Цифровое изображение Программы Microsoft Windows UNIX Другие OS Hardware В помощь сисадмину Прикладное программирование Игры Форумные игры   » Интернет Web-программирование В помощь вебмастеру Графика Хостинг Зацените-ка!   » Тематические Ikonboard v.2 Ikonboard v.3 Invision Board Другие форумы PHP-Nuke и другие порталы Мобила   » Общие Спорт Флейм Темы по региональным встречам Музыка и Кино Юмор Литература и Живопись   » Ru.Board Новости Помощь по форуму   » Андеграунд eBookz Варезник Раздачи и акции Мобильный варезник Андеграунд Игры и фильмы   » Специальные Тестирование