Delphi консультации (бесплатно)

  • Автор теми Автор теми crghome
  • Дата створення Дата створення
А все-таки, почему с sharp - 1026, а Java - 675 на моей машине? Что там еще соптимизировать-то?:)
 
silv сказав(ла):
А все-таки, почему с sharp - 1026, а Java - 675 на моей машине? Что там еще соптимизировать-то?:)
Натисніть, щоб розгорнути...

Почему у Java 675, нужно смотреть по коду производимому JIT компилятором.
Кстати, если пример на C# скомпилить с оптимизацией, то будет 0 мс, JIT гад оптимизирует даже если вставить в функцию код изменяющий статик переменную и печатать эту переменную после цикла. В этом случае вместо цикла JIT просто тупо подставляет загрузку в регистр готового результата который должен получиться после работы цикла, и весь цикл превращается в один опкод загружающий в регистр готовый результат :D
 
Это я лично проверил, что оптимизатор работает как следует. Проверял в Visual C++ 2010. 0 ms :)
Но 675? Такое впечатление, Java код разогнался, понял, что делает херню и вывел готовый результат :)
З.Ы. гуру Жабы, есть ли способ посмотреть исполняющийся код?
 
можно подставить в код
Код: 
for(;;);
запустить и заатачится отладчиком ;)
 
Появился вопрос к специалистам, точнее нужен совет.
В моем проекте есть два модуля с указателем на объект, один обрабатывает ввод в TEdit(Edit:TEdit; Key:char) и TStringGrid(Str:TStringGrid; Key:char) (вводятся только реал числа, и некоторые исключения), второй удаляет и добавляет строки в TStringGrid (происходит в определенной ARow не теряя при этом данных с остальных ячеек). Так вот в чем вопрос, посоветуйте как будет наиболее оптимально (с учетом использования этих модулей в других проектах, и со временем дальнейшего расширения):
- создание класса;
- создание dll;
- использовать как "модули процедур".
Пока к protected методам классов, от которых происходит наследование данных модулей, не обращаюсь. Кто что может посоветовать?

Использование приблизительно следующее:
Код: 
procedure MyForm.EditOnKeyPresed(...., var Key:char);
begin
Unit_Edit.EditKey(MyForm.Edit; Key);
end;
 
crghome сказав(ла):
Появился вопрос к специалистам, точнее нужен совет.
В моем проекте есть два модуля с указателем на объект, один обрабатывает ввод в TEdit(Edit:TEdit; Key:char) и TStringGrid(Str:TStringGrid; Key:char) (вводятся только реал числа, и некоторые исключения), второй удаляет и добавляет строки в TStringGrid (происходит в определенной ARow не теряя при этом данных с остальных ячеек). Так вот в чем вопрос, посоветуйте как будет наиболее оптимально (с учетом использования этих модулей в других проектах, и со временем дальнейшего расширения):
- создание класса;
- создание dll;
- использовать как "модули процедур".
Пока к protected методам классов, от которых происходит наследование данных модулей, не обращаюсь. Кто что может посоветовать?

Использование приблизительно следующее:
Код: 
procedure MyForm.EditOnKeyPresed(...., var Key:char);
begin
Unit_Edit.EditKey([SPOILER="MyForm."]Какой *** МyForm. ты уже в методе класса используй его члены?[/SPOILER][SPOILER="Edit"]Для этого у ивента есть Sender[/SPOILER]; Key);
end;
Натисніть, щоб розгорнути...
:рл: Кто ясно мыслит, тот ясно излагает. У тебя все с точностью до наоборот.
Походу у тебя есть модули с обработчиками ивентов. Так вот правильное решение - создать свои компоненты. Ну а как временное решение сделать DataModule перенести в его паблишед секцию обработчики и назначать их в dfm.
Ну и использование в обработчике чего то помимо параметров обработчика (без реальной на то нужды) это ламерство еще то. А за использование внутри метода класса ссылки на глобальную переменную экземпляр класса в приличной компании можно и канделябром по физии выгрести.

crghome сказав(ла):
Просто мне не очень интересно развивать полемику и тягаться в знаниях с более опытным, а честно я не представляю к чему ты придрался (если насчет сравнения с ооп, так это абстрактно - технологии то разные), да как то и не важно.
Натисніть, щоб розгорнути...
Какая полемика. Твой пост состоял из бессвязного набора терминов и междометий. Если слабо представляешь себе о чем речь, так и не лезь поперед батьки в пекло.
 
Останнє редагування:
Зависит от размера кода
Для лабораторки можно не заморачиваться
Для большого проекта можно прочесть про паттерны и создать класс, который будет рассылать уведомления о событиях и приемников.
 
Сначала извинюсь за мой плохой разговорный.
Затем:
vitos сказав(ла):
Ну а как временное решение сделать DataModule перенести в его паблишед секцию обработчики и назначать их в dfm.
Натисніть, щоб розгорнути...
Вот это у меня сейчас. Вынес так, потому что: 1) постоянно и во многих объектах возникает необходимость проверки бизнес правил; 2) для использования данного модуля в дальнейшем.

vitos сказав(ла):
Какой *** МyForm ты уже в методе класса используй его члены? Для этого у ивента есть Sender
Натисніть, щоб розгорнути...
vitos сказав(ла):
использование внутри метода класса ссылки на глобальную переменную экземпляр класса
Натисніть, щоб розгорнути...
У меня в "DataModule" (Unit_Edit) обработчики именуются:
procedure EditKey(Sender:TEdit; Key:char);
а в вызове данной процедуры указываю на объект в котором необходима проверка (напр. в пустом Edit'e нажимается ',' или '.', в поле Edit'a появляется '0,' (лучше описать не смог); и подобные операции).
Вызов правильно?:
Код: 
procedure Form1.Edit1KePresset(Sender:TEdit; var Key:char);
begin
EditKey(Sender, Key);
end;
Не посоветуешь, как обращаться с DаtaModule к методам TEdita на форме что бы не "получить канделябром по физии"?

Такой метод нашел в DelphiWord вот и спросил правильно ли я делаю, вижу все не так уж и правильно. В дальнейшем разработаю компонент.
 
Останнє редагування:
Создать паблишед метод в классе формы. Который принимает нужные данные и потом обращается к tedit. Небольшой оаерхед компенсируется дальнейшей поддержкой.
Глобальные переменные экземпляра класса, которые делает сама delphi, лучше вообще не использовать.
 
dgr сказав(ла):
От ненада мне тут сказки рассказыавть ибо я таки да - software devloper ;) Область приминения дельфи весьма ограниченная - в основном ее использовали для разработки всяких бухгалтерских систем.
Натисніть, щоб розгорнути...

:eek:

"Моя мася!"

На Дельфи великолепно пишутся COM-объкты, реализующие решение решение дифференциальных уравнений и систем уравнений итеррационными методами.
Я не говорю о простоте написания интерфейсов. Если не использовать дотНет, то Дельфи, как инструмент не имеет себе равных по удобству и скорости написания пользовательских интерфейсов и "морд".

Правильно говорить, что на Дельфи можно писать все. Но драйвера удобней писать на С.
 
Драйверы удобнее писать, юзая WinDriver + Delphi/C++/C/C#

Я тут пока тестирую мелочи для своего применения в C#, но уже есть затыки с GC. Он срабатывает когда мне не надо. Наверное, попробую руками заставлять его работать.

Еще из приколов - исправлял недавно глюк один.
Есть OCX на WinForm. Программа форму создает, юзает компоненту, форму убивает. И так 1000 раз.
Так вот память не освобождалась, при удалении формы память, отожранная OCX, оставалась занята.
Понятно, что это не .NET компонент, но по логике при уничтожении формы память должна была освобождаться.
Руками поправил.
 
RainBoy сказав(ла):
Я тут пока тестирую мелочи для своего применения в C#, но уже есть затыки с GC. Он срабатывает когда мне не надо. Наверное, попробую руками заставлять его работать.
Натисніть, щоб розгорнути...

проблемы с GC обычно начинаются когда в него лезут руками и пытаются как-то заставлять его работать :) Чтобы вмешиваться в механизм сборки, нужно глубоко и хорошо понимать как GC работает. Если нет знания как устроены внутренности GC, то попытки оптимизации сборки мусора с вероятностью 99% приведут к ухудшению ;)

А в чем собственно проблема со сборкой заключается?

RainBoy сказав(ла):
Понятно, что это не .NET компонент, но по логике при уничтожении формы память должна была освобождаться.
Руками поправил.
Натисніть, щоб розгорнути...

по какой такой логике? :confused: В сборке мусора нет ничего сверхестественного, GC чистит только managed память. Все что касается unmanaged кода лежит на совести программиста.
 
Klez сказав(ла):
проблемы с GC обычно начинаются когда в него лезут руками и пытаются как-то заставлять его работать :) Чтобы вмешиваться в механизм сборки, нужно глубоко и хорошо понимать как GC работает. Если нет знания как устроены внутренности GC, то попытки оптимизации сборки мусора с вероятностью 99% приведут к ухудшению ;)

А в чем собственно проблема со сборкой заключается?

по какой такой логике? :confused: В сборке мусора нет ничего сверхестественного, GC чистит только managed память. Все что касается unmanaged кода лежит на совести программиста.
Натисніть, щоб розгорнути...

Я это понимаю. Есть OCX компонент на форме, форма разрушается - что делается с OCX? Он остается висеть в памяти. .NET создает это объект при создании формы, но не уничтожает.

Проблема со сборкой в том, что она запускается когда мне нежелательно. Пока только первые наметки, когда все нормально просмотрю распишу подробно.
 
crghome сказав(ла):
Сначала извинюсь за мой плохой разговорный.
Затем:

Вот это у меня сейчас. Вынес так, потому что: 1) постоянно и во многих объектах возникает необходимость проверки бизнес правил; 2) для использования данного модуля в дальнейшем.



У меня в "DataModule" (Unit_Edit) обработчики именуются:
procedure EditKey(Sender:TEdit; Key:char);
а в вызове данной процедуры указываю на объект в котором необходима проверка (напр. в пустом Edit'e нажимается ',' или '.', в поле Edit'a появляется '0,' (лучше описать не смог); и подобные операции).
Вызов правильно?:
Код: 
procedure Form1.Edit1KePresset(Sender:TEdit; var Key:char);
begin
EditKey(Sender, Key);
end;
Не посоветуешь, как обращаться с DаtaModule к методам TEdita на форме что бы не "получить канделябром по физии"?

Такой метод нашел в DelphiWord вот и спросил правильно ли я делаю, вижу все не так уж и правильно. В дальнейшем разработаю компонент.
Натисніть, щоб розгорнути...
На все твои вопросы уже были даны исчерпывающие ответы. Повторяться нет смысла. Не понял в первый раз - не поймешь и во второй.
 
RainBoy сказав(ла):
Можно, но когда разберусь побольше
Дабы **** не показывать :D
Натисніть, щоб розгорнути...

могу сказать что с заполнением аудиобуффера + синтез аудиопотока в рантайме, C# справляется очень даже хорошо. А это realtime задача и по сути, судя по всему, очень похожа на твою ;)
 
Не очень
У меня прошлое по четко 2 раза в милисекунду собирает данные
Второй поток обрабатывает, но уже не так привязанно ко времени
За задержки при сборе - ********
 
Wild Mouse сказав(ла):
:eek:

"Моя мася!"

На Дельфи великолепно пишутся COM-объкты, реализующие решение решение дифференциальных уравнений и систем уравнений итеррационными методами.
Я не говорю о простоте написания интерфейсов. Если не использовать дотНет, то Дельфи, как инструмент не имеет себе равных по удобству и скорости написания пользовательских интерфейсов и "морд".

Правильно говорить, что на Дельфи можно писать все. Но драйвера удобней писать на С.
Натисніть, щоб розгорнути...
:рл:
что ж.. пишите, Шура, пишите(с) :D Чем больше таких писак, тем больше будет работы у меня. ;)
Продолжай в том же духе :клас:
:іржач::іржач::іржач:

RainBoy сказав(ла):
Драйверы удобнее писать, юзая WinDriver + Delphi/C++/C/C#
Натисніть, щоб розгорнути...

Пример драйвера на С# можно глянуть? ;)
 
Ви повинні увійти або зареєструватися, щоб відповісти.
Назад
Зверху Знизу