Здравствуйте, Don Reba, Вы писали:
H>>Цифры в студию Боюсь, только, даже на миллионе итераций разница будет в микросекундах. А теперь прикинь, как нечасто вызываются эти функции.
DR>Немного пугает лёгкость с которой ты бросаешься терагерцами.
Здравствуйте, hattab, Вы писали: H>Нужно понимать, что предлагают инлайнить. Предлагают инлайнить функции вызывающиеся настолько редко, что ни какой выгоды от этого мы не получим вообще.
Можно взглянуть на это и по-другому. Функции вызываются редко, следовательно, проигрыш в размере исполняемого файла будет невелик.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, hattab, Вы писали: H>>Нужно понимать, что предлагают инлайнить. Предлагают инлайнить функции вызывающиеся настолько редко, что ни какой выгоды от этого мы не получим вообще.
MC>Можно взглянуть на это и по-другому. Функции вызываются редко, следовательно, проигрыш в размере исполняемого файла будет невелик.
Представь другую ситуацию: их много и они размазаны по сложному коду, где на один их вызов будет происходить куча других операций. Я вообще не понимаю фига это обсуждать без цифр полученных на реальном приложении
Здравствуйте, koandrew, Вы писали:
H>>Повышение производительности за счет инлайнинга операций подсчета ссылок, это сродни полировке заклепок на танке, в надежде улучшить его аэродинамику.
K>Мда... Мозги у вас зашорены основательно. Ну подумайте сами — имеет ли смысл не инлайнить функции, расходы на исполнение которой сопоставимо с расходами на её вызов? Ведь в случае инлайна прирост производительности этого фрагмента будет очень серьёзным...
Меня вдруг осенило! А их же вообще нельзя заинлайнить, это же методы интерфейса, о реализации которого, по определению, компилятор не имеет понятия
Здравствуйте, hattab, Вы писали: H>Представь другую ситуацию: их много и они размазаны по сложному коду, где на один их вызов будет происходить куча других операций. Я вообще не понимаю фига это обсуждать без цифр полученных на реальном приложении
Без цифр — согласен, фигово. Однако вызов функции посреди сложного кода будет негативно сказываться на его производительности (хотя со сбросом конвейера я погорячился, конечно — но негатив будет хотя бы из-за того, что выборка команд не будет последовательной — а будет "скакать").
Здравствуйте, _d_m_, Вы писали: ___>Синклар, от тебя не ожидал — это не аргумент. Угробищную программу можно написать на любом языке,
Совершенно верно. Это и был мой аргумент.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kuj, Вы писали: kuj>Смею предположить, что сие утверждение просто говорит о том, что ты плохо знаешь Java. Да, лет семь уже на ней не писал ничего.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, hattab, Вы писали:
H>Меня вдруг осенило! А их же вообще нельзя заинлайнить, это же методы интерфейса, о реализации которого, по определению, компилятор не имеет понятия
Неверно тебя осенило Я не предлагал инлайнить реализацию Release() (хотя современные С++ компиляторы в ряде случаев умеют устранять виртуальность ) — говорю о ф-ции IntfClear или как она там называется. Сама ф-ция — десяток ассемблерных команд, поэтому время их выполнения будет сравнимо с временем вызова ф-ции. Но дело не в этом конкретном случае — вам тут уже рекомендовали расширить сознание — если компилер не может инлайнить даже такие простые случаи, то он не может инлайнить ничего вообще. Кстати об этом косвенно говорит тот факт, что дельфи-программы можно построчно дебажить в релизном варианте (что автоматически означает отсутствие всяких инлайнов).
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, _d_m_, Вы писали:
kuj>>>В действительности вышеописанных граблей ни в одной нормальной среде разработки быть не должно.
kuj>>>Конечно определенные грабли есть везде — где-то меньше, где-то больше. Регулярно пользуюсь VS 2005, VS 2008, пару лет тому назад еще IntelliJ IDEA в арсенале была. Все отлично — на грабли натыкаться не приходиться, работать одно удовольствие.
___>>Да есть тоже немножко. Сейчас пользуем VS 2005 SP1: ___>>- Если попробовать в док. комментариях добавить для достаточно большого файла ___>>/// <summary> ___>>/// asda ___>>/// </summary> ___>>/// <param name="dsda"> asas /</param> ___>>вот например в этом месте попытаться напечатать слэш — студия виснет.
kuj>Хмм, интересно. На сколько большой должен быть файл, чтоб студия зависла? На .cs в 360kB не виснет и не тормозит... Большего cs-файла под рукой нету...
Ну не такой уж большой — 69К. Проблема проявляется именно в этом файле. Скорее всего проблема возникает из-за содержимого, но то что проблема воспроизводима — это факт.
___>>- До SP1 одолевал WinForms дизайнер — открываешь допустим свой контрол, а на нем кнопки съехали. Ну это уже не в счет.
kuj>Не сталкивался. Я, правда, с WinForms мало работаю.
___>>- WinForms дизайнер — шрифты в дизайнере могут оказаться другого размера, чем на реальной форме.
kuj>Это как? Можно сценарий для воспроизведения?
Вот:
Слева кнопка в дизайнере, справа реально запущенное приложение. MS Sans Serif 9.75pt.
___>>- Есть проблемы с дизайнером ReportViewer-а — преобразование единиц измерения, например мм-см, и прочие мелочи типа неверного преобразования margins страницы — это самое неприятное.
kuj>Ну это скорее глюк ReportViewer`а?
Здравствуйте, hattab, Вы писали:
H>У интерфейсов нет понятий видимости или невидимости методов. Интерфейс рассматривается только в целом. Тот факт, что второй интерфейс не совместим с типами COM, делает его не COM интерфейсом.
COM интерфейсом делает наследие от IUnknown.
Методы в принципе могут быть любыми. Если ты используешь другое соглашение о вызове, то этот объект может быть использовать только в среде Delphi. Если аргументы не являются variant — совместимыми, то нелюзя вызывать метоеды через IDispatch.
Здравствуйте, hattab, Вы писали:
H>Объясняю еще раз, для особо одаренных. Сегодня ты должен спроектировать класс, и реализовать его так, чтоб завтра, некто другой мог получить (или проверить на возможность получения) от этой сущности другую сущность, о наличии которой тебе на момент проектирования не известно. Работая с объектами ты этой задачи не решишь, ну или изобретешь свой аналог GetInterface/QueryInterface.
Ты сейчас как-то криво рассказал про фабрику классов. Тольео её придумали гораздо раньше COM
Кстати COM нужен не для получения сущности (хотя непонятно чт ты имеешь ввиду) о наличии которой неизвестно на момент проектирования.
COM — бинарный стандарт повтороно используемых компонент. Все компоненты знают на момент проектирования какие инерфейсы они поддерживают
В статье есть ответ ровно на один вопрос: какие порты. Больше ровным счетом ничего — ни механизма обмена (со стороны ОС, а не .Net сборки), ни методов аутентификации, ничего. Еще раз повторяю — даже если кодер не заморачивается такими вопросами (вообще говоря, и не должен) — все эти вопросы должны появится в голове у архитектора.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, DOOM, Вы писали:
DOO>>Здравствуйте, kuj, Вы писали:
kuj>>>1. У Javascript есть нормальный garbage collector. Ему не нужны smart pointer`ы. DOO>>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша. G>Не показывай свою необразованность. В C нет обънектов, смарт поинтеры там не нужны.
Хорош уже откровенно тупить — где написано, что как только появляются объекты, то нужны смарт пойнтеры? Ты бы еще сказал, что на C нельзя написать <подставь сюда свой типичный проект>, потому что там нет объектов! Я тебе и привожу примеры, где прекрасно живется без твоих смарт пойнтеров — не важно по какой причине. В дельфи, к пример, все наследники TComponent'а в обязательном порядке обладают owner'ом — который отвечает за убийство своих подопечных, когда умирает сам. Соответственно все завязано на основную форму приложения, а значит все объекты будут корректно уничтожены рано или поздно — это вариант борьбы с отсутствием автоматического контроля времени жизни объекта. И, если человек хоть немного понимает, что такое указатель, объект и т.п., то у него не будет проблем с утечками.
Почему что, господа апологеты C++ забывают про знаменитые грабли под названием конструктор копирования, например — вот уж сколько ошибок вызывает его некорректное определение или непонимание, когда он вызовется.
kuj>>>2. Делфи — динамический язык? DOO>>В достаточной мере. G>Не более динаический, чем С++. Можно везде писать (void*) и кастить при каждом обращении.
Да... Ну ладно — тогда создай мне экземпляр класса по его строковому имени в ран-тайме. Или хотя бы перечисли методы объекта в ран-тайме.
Да, конечно, в Дельфи нету JIT'а, но и статическим строго типизированным его не назовешь.
kuj>>>А Борланд об этом знает? DOO>>Да уж наверное. Хотя в 6-й дельфи они стали на многие прикольные фишки выдавать ворнинги, что в .Net версии это уже не будет работать. G>Наверное ворнинги не от хорошей жизни.
Ворнинги от того, что в .Net банально многое нельзя, а значит программа не перенесется в среду .Net.
kuj>>>Ликбез: Delphi, C++ и C# — статические строго типизированные языки. DOO>>На вскидку из гугла: DOO>>
DOO>>TabGrid := VarArrayCreate([0,(R - 1),0,(C - 1)],VarOleStr);
DOO>> I := 0;
DOO>> // Определяем цикл для заполнения массива-матрицы
DOO>> repeat
DOO>> for J := 0 to (C - 1) do
DOO>> TabGrid[I,J] := GenericStringGrid.Cells[J,I];
DOO>> Inc(I,1);
DOO>> until
DOO>> I > (R - 1);
DOO>>
DOO>>Опа. Не попадает как-то в узкие рамки статической строгой типизации? Причем заметь — надо писать не что-то вроде SetVariantArrayValue(TabGrid,i,j), а просто TabGrid[i,j] — при этом TabGrid не является массивом до момента выполнения строчки TabGrid := VarArrayCreate([0,(R — 1),0,(C — 1)],VarOleStr); G>И ты этим гордишься? Это бездонная бочка ошибок на самом деле.
kuj>>>Ликбез: Delphi, C++ и C# — статические строго типизированные языки.
DOO>>На вскидку из гугла:
Я не горжусь, а показываю тебе, да kuj'у ваши заблуждения. А твоя фраза очень неплохо попадает под один из приемов женской логики:
* В женской логике каждое утверждение может быть не только опровергнуто, но и отвергнуто. Отвергая высказывание, вы признаете его бессмысленным и оставляете без внимания. Если вы отвергли последнее высказывание собеседницы, ваше предпоследнее утверждение остается без ответа и, таким образом, становится доказанным. Например, самые основательные соображения можно отвергнуть словами "Ну и что?" или "А больше ничего не смог придумать?".
Так что подумай над своими методами ведения спора.
DOO>>Ну а ты пальцы гнуть бы завязывал... G>Ты бы завязывал писать глупости
А ты покажи хотя бы одну. Да еще обоснованно.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, DOOM, Вы писали:
kuj>>>1. У Javascript есть нормальный garbage collector. Ему не нужны smart pointer`ы. DOO>>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша. kuj>Кроме Delphi. Ее мини-ниша полностью занята .NET
Во-первых, RAD — это не мини ниша.
Во-вторых, я и не спорю. Хот замечу, что Qt под Linux пока сильнее, чем Mono...
kuj>>>2. Делфи — динамический язык? DOO>>В достаточной мере. kuj>Скажу тебе по секрету Delphi никогда не был, не является, и вряд ли когда-то станет динамическим языком.
В полной мере нет. Но не все так строго делится на белое и черное. Delphi является более динамическим, чем C++, например.
kuj>>>А Борланд об этом знает? DOO>>Да уж наверное. Хотя в 6-й дельфи они стали на многие прикольные фишки выдавать ворнинги, что в .Net версии это уже не будет работать. kuj>И при чем тут динамические языки?
Это к вопросу о статической типизации. Или ты под динамическим языком понимаешь только тот, у которого есть функция типа eval?
kuj>>>Если хочешь посмотреть на динамический язык возьми ruby или python, например. DOO>>Кстати, мое первое впечатление от питона было — о! Дельфи в виде скрипта. Очень много похожего. kuj>Всего-лишь говорит о твоей низкой квалификации, если для тебя "Питон — это дельфи в виде скрипта".
Я бы на твоем месте ярлыки не вешал и квалификацию других людей не оценивал.
kuj>>>Ликбез: Delphi, C++ и C# — статические строго типизированные языки. DOO>>На вскидку из гугла: DOO>>
DOO>>TabGrid := VarArrayCreate([0,(R - 1),0,(C - 1)],VarOleStr);
DOO>> I := 0;
DOO>> // Определяем цикл для заполнения массива-матрицы
DOO>> repeat
DOO>> for J := 0 to (C - 1) do
DOO>> TabGrid[I,J] := GenericStringGrid.Cells[J,I];
DOO>> Inc(I,1);
DOO>> until
DOO>> I > (R - 1);
DOO>>
DOO>>Опа. Не попадает как-то в узкие рамки статической строгой типизации? Причем заметь — надо писать не что-то вроде SetVariantArrayValue(TabGrid,i,j), а просто TabGrid[i,j] — при этом TabGrid не является массивом до момента выполнения строчки TabGrid := VarArrayCreate([0,(R — 1),0,(C — 1)],VarOleStr);
kuj>VarArrayCreate создает массив значений типа Variant. При чем тут динамические языки? Ты, батенька, серьезно не в теме.
В VBscript'е любая переменаая это тоже Variant — если ты внедришь движок VB через соответсвующий COM объект в свою программу, то ты даже сможешь получать к ним доступ. Вопрос в прямой поддержке со стороны языка — VBScript поддерживает эти Variant'ы прозрачно, Delphi — тоже, C++ — нет. Соотвественно нельзя говорить, что в Delphi статическая типизация. Все, что отличает его от какого-нибудь скрипта — это отсутствие функции типа eval. Это делает Дельфи некоторым промежуточным языком, но ни как не "статическим языком со строгой типизацией".
Еще интереснее было бы поглядеть на внутренности Perl'а и, так называемые, xsub — здесь уже получается смесь перловского интерфейса с классическим. Дак что, после этого Perl становится статическим языком со строгой типизацией?
kuj>Проку от них ровно столько, сколько проку от подобного контейнера в Delрhi. Кроме того, что я могу явно ограничить супертип, что уменьшит поле для ошибок на этапе компиляции. Вообщем, ты снова явно не в теме.
Для особо одаренных напомню, что в дельфи все объпекты потомки TObject — т.е. супертип уже ограничен. Прямо такой уж жизненной необходимости отсекать дерево при помощи какого-то промежуточного объекта я не вижу — это можно сделать еще в куче мест, в том числе в рантайме.
P.S. Выделенное я мог бы тебе сказать уже раз так много, но не имею привычки судить о познаниях человека заочно. Тебе бы тоже не советовал.
Здравствуйте, DOOM, Вы писали:
DOO>Хорош уже откровенно тупить — где написано, что как только появляются объекты, то нужны смарт пойнтеры? Ты бы еще сказал, что на C нельзя написать <подставь сюда свой типичный проект>, потому что там нет объектов!
Смарт-поинтеры нужны в C++, потому что можно забытьнаписать delete. Они также нужны в Delph, потому что там можно забыть написать Free.
Любоую программу можно написать без объектов, только вопрос времени.
DOO>Я тебе и привожу примеры, где прекрасно живется без твоих смарт пойнтеров — не важно по какой причине.
Что-то я не увидел примеров.
DOO>В дельфи, к пример, все наследники TComponent'а в обязательном порядке обладают owner'ом — который отвечает за убийство своих подопечных, когда умирает сам.
Только далеко не все классы являются наследниками TComponent DOO>Соответственно все завязано на основную форму приложения, а значит все объекты будут корректно уничтожены рано или поздно — это вариант борьбы с отсутствием автоматического контроля времени жизни объекта.
Выделенное — офигенный недостаток.
DOO>И, если человек хоть немного понимает, что такое указатель, объект и т.п., то у него не будет проблем с утечками.
В .NET и Java у человека не будет проблем с утечками даже если он не понимает указатели.
kuj>>>>2. Делфи — динамический язык? DOO>>>В достаточной мере. G>>Не более динаический, чем С++. Можно везде писать (void*) и кастить при каждом обращении. DOO>Да... Ну ладно — тогда создай мне экземпляр класса по его строковому имени в ран-тайме. Или хотя бы перечисли методы объекта в ран-тайме.
В С++ нет метаданных, поэтому такое невозможно. Но налитчие метаданных не делает язык динамическим.
В .NET и Java есть метаданные, но они не позиционируются как динамические языки.
DOO>Да, конечно, в Дельфи нету JIT'а, но и статическим строго типизированным его не назовешь.
Еще как назовешь. В динамических языках контроль типа осуществляется на стадии компиляции. Нельязя в делфи сравнить число со строкой, будет ошибка компиляции. то и есть проявление счтатической типизации.
В Javascript например написать сравнение числа со строкой вполне можно, это вызвоет ошибку времени выполнения.
DOO>Ворнинги от того, что в .Net банально многое нельзя, а значит программа не перенесется в среду .Net.
В .NET можно сделать все, что можно в делфи.
DOO>Так что подумай над своими методами ведения спора.
То есть ты хочешь сказать что использование вариантных типов не приводит к увечличению числа ошибок?
DOO>>>Ну а ты пальцы гнуть бы завязывал... G>>Ты бы завязывал писать глупости DOO>А ты покажи хотя бы одну. Да еще обоснованно.
Глупость номер раз — Delphi динамический язык
Глупость номер два — использование вариантных типов везде.
Здравствуйте, hattab, Вы писали:
H>Я не говорю о плюсах Абрамса (а Oracle стоял на Тамагавках), я говорю, что этот факт хоть как-то, но характеризует Interbase
Нет, этот факт характеризует Абрамс — да и никто не застрахован от неудачных решений и выбора. А с Interbase я знаком не понаслышке и мне есть с чем сравнивать. Даже ярые апологеты FB отзаваются об Interbase достаточно не лестно.
H>Вот еще: H>
Еще
H> один малоизвестный факт — использование InterBase для хранения
H> информации о кредитках в считывающих устройствах, которые используются
H> на немецких железных дорогах — одной из самых быстрых и развитых
H> транспортных систем в мире.
"никто не застрахован от неудачных решений и выбора". И это вероятно случилось после того, как исходники IB были выложены Богланд, видать сами рихтуют косяки.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Сергей, Вы писали:
kuj>>>Есть Wix, который лучше за счет простоты использования в continous integration процессе.
С>>Лучше ли Wix, чем InnoSetup, спорить не хочу, но Wix — это другое. Это для создания MSI-инсталлеров.
kuj>И что? Чем не угодили MSI-инсталлеры? А про ClickOnce слышать доводилось?
kuj>>>Пишешь .NET сборку со сколь угодно богатым интерфейсом, делаешь ее COM-visible. Пишешь dll на C++, которая будет выполнять роль медиатора. Все.
С>>С прослойкой на C++ можно и на яваскрипте написать.
kuj>Богатый интерфейс на яваскрипте? Флаг в руки, ветер в спину.
А в чем проблема? Можно и интерфейс. Можно и прямо COM объект настрочить на JS (точнее, конечно, это WSH)... Не знал?
Здравствуйте, koandrew, Вы писали:
H>>Меня вдруг осенило! А их же вообще нельзя заинлайнить, это же методы интерфейса, о реализации которого, по определению, компилятор не имеет понятия
K>Неверно тебя осенило Я не предлагал инлайнить реализацию Release() (хотя современные С++ компиляторы в ряде случаев умеют устранять виртуальность ) — говорю о ф-ции IntfClear или как она там называется. Сама ф-ция — десяток ассемблерных команд, поэтому время их выполнения будет сравнимо с временем вызова ф-ции. Но дело не в этом конкретном случае — вам тут уже рекомендовали расширить сознание — если компилер не может инлайнить даже такие простые случаи, то он не может инлайнить ничего вообще. Кстати об этом косвенно говорит тот факт, что дельфи-программы можно построчно дебажить в релизном варианте (что автоматически означает отсутствие всяких инлайнов).
Delphi программы в релизном варианте не поотлаживаешь. Отключи DebugInfo и отладчик работать перестанет. По поводу IntfClear... Ты сам понимаешь нелепость своего предложения об инлайне? Давай уже цифры.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, hattab, Вы писали: H>>Цифры в студию Боюсь, только, даже на миллионе итераций разница будет в микросекундах.
MC>Вызов функции — это сброс конвейера. Ничего хорошего в этом нет.
Здравствуйте, DOOM, Вы писали:
kuj>>Богатый интерфейс на яваскрипте? Флаг в руки, ветер в спину. DOO>А в чем проблема? Можно и интерфейс. Можно и прямо COM объект настрочить на JS (точнее, конечно, это WSH)... Не знал?
Да ну, а пример покажешь?
Боюсь, только, даже на миллионе итераций разница будет в микросекундах. А теперь прикинь, как нечасто вызываются эти функции.
