Здравствуйте, _d_m_, Вы писали:

___>Про Дельфи не скажу, но от поделий Богланд меня что-то воротит. Может вспомним еще угробище под названием Interbase?

Тссс! Щас фанаты Firebird повылазят...

Здравствуйте, DOOM, Вы писали:


kuj>>Ты не понял. Во-первых, в C++ можно и std::list< void * >, во-вторых, это дает не гибкость, а широкое поле для ошибок и проблем с приведением типов.
DOO>И снова мы упираемся в различные подходы — для тебя программа во время выполнения статична, для дельфиста — нет.
Ась?


kuj>>И конечно же негативно сказывается на производительности.
DOO>Это почему?
Потому, что приведение типов.

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, DOOM, Вы писали:


kuj>>>Ты не понял. Во-первых, в C++ можно и std::list< void * >, во-вторых, это дает не гибкость, а широкое поле для ошибок и проблем с приведением типов.
DOO>>И снова мы упираемся в различные подходы — для тебя программа во время выполнения статична, для дельфиста — нет.
kuj>Ась?
Да елки-палки. Вот есть у меня TList — я в него что-то складываю в функции, полученное параметром к этой самой функции — никто не знает до этапа выполнения, что там будет — какой такой объект? Какого такого типа? Такие ситуации встречаются очень даже часто — и проку мне от твоего типизированного контейнера?
Я реально в свое время был просто в каком-то мега восторге, что я могу определить минимум на этапе написания и сделать все функции и объекты универсальными...


kuj>>>И конечно же негативно сказывается на производительности.
DOO>>Это почему?
kuj>Потому, что приведение типов.
o_O И какие же это накладные расходы в run time? Особенно хотелось бы услышать про накладные расходы у приведений вида:

void *ptr;
...
(char *)ptr

Здравствуйте, DOOM, Вы писали:

Мда, сколько бреда понаписывал.

1. У Javascript есть нормальный garbage collector. Ему не нужны smart pointer`ы.
2. Делфи — динамический язык? А Борланд об этом знает? Если хочешь посмотреть на динамический язык возьми ruby или python, например.
Ликбез: Delphi, C++ и C# — статические строго типизированные языки. Неужто ты серьезно думаешь, что если есть generic`и, то пропадает возможность кастинга объекта к суперклассу?


Серьезно, ребят, завязывайте с Delphi. Delphi — зло, оно отупляет.

Здравствуйте, DOOM, Вы писали:

kuj>>>>Ты не понял. Во-первых, в C++ можно и std::list< void * >, во-вторых, это дает не гибкость, а широкое поле для ошибок и проблем с приведением типов.
DOO>>>И снова мы упираемся в различные подходы — для тебя программа во время выполнения статична, для дельфиста — нет.
kuj>>Ась?
DOO>Да елки-палки. Вот есть у меня TList — я в него что-то складываю в функции, полученное параметром к этой самой функции — никто не знает до этапа выполнения, что там будет — какой такой объект? Какого такого типа? Такие ситуации встречаются очень даже часто — и проку мне от твоего типизированного контейнера?

Что запрещает использовать IList<object> ? Религия?

kuj>>>>И конечно же негативно сказывается на производительности.
DOO>>>Это почему?
kuj>>Потому, что приведение типов.
DOO>o_O И какие же это накладные расходы в run time? Особенно хотелось бы услышать про накладные расходы у приведений вида:
DOO>

DOO>void *ptr;
DOO>...
DOO>(char *)ptr 
DOO>

RTFM.

Здравствуйте, se_sss, Вы писали:

_> Легко. Лично сталкивался с ситуацией когда на одной из моторол (платформа Java ME)после каждого проигрывания wav-файла число потоков в системе всегда увеличивалось и не уменьшалось никакими средствами.
_>Понятно, что это вина не джавы, как таковой, а корявой реализации библиотек производителями телефонов, не всё же...

А GC тут при чем?

Здравствуйте, _d_m_, Вы писали:

___>На C# этот вирус работал бы лучше и эффективнее

Угу, и мусор за собой бы убирал.

Здравствуйте, hattab, Вы писали:

H>>>Мы говорим об интерфейсах, а точне о COM-интерфейсах (где есть AddRef и Release).

G>>Еще раз, запомни простую вещь: в .NET нету разницы между COM и не-COM

H>Ок. У .Net-интерфейсов есть механизм подсчета ссылок? И почему мне Mr.Cat говорил, что не в курсе, как устроен GC для COM-интерфейсов? Есть какое-то различие? Просвети.

Ты статью в codeproject, ссылку на которую я тебе дал, явно не читал. Объясни почему мы должны тут восполнять пробелы в твоем образовании? Назови хоть одну причину.

Здравствуйте, kuj, Вы писали:

kuj>1. У Javascript есть нормальный garbage collector. Ему не нужны smart pointer`ы.
Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша.

kuj>2. Делфи — динамический язык?
В достаточной мере.

kuj>А Борланд об этом знает?
Да уж наверное. Хотя в 6-й дельфи они стали на многие прикольные фишки выдавать ворнинги, что в .Net версии это уже не будет работать.


kuj>Если хочешь посмотреть на динамический язык возьми ruby или python, например.
Кстати, мое первое впечатление от питона было — о! Дельфи в виде скрипта. Очень много похожего.


kuj>Ликбез: Delphi, C++ и C# — статические строго типизированные языки.
На вскидку из гугла:

TabGrid := VarArrayCreate([0,(R - 1),0,(C - 1)],VarOleStr);
    I := 0;
    //  Определяем цикл для заполнения массива-матрицы
    repeat
    for J := 0 to (C - 1) do
      TabGrid[I,J] := GenericStringGrid.Cells[J,I];
    Inc(I,1);
    until
    I > (R - 1);

Опа. Не попадает как-то в узкие рамки статической строгой типизации? Причем заметь — надо писать не что-то вроде SetVariantArrayValue(TabGrid,i,j), а просто TabGrid[i,j] — при этом TabGrid не является массивом до момента выполнения строчки TabGrid := VarArrayCreate([0,(R — 1),0,(C — 1)],VarOleStr);


kuj>Неужто ты серьезно думаешь, что если есть generic`и, то пропадает возможность кастинга объекта к суперклассу?
Нет не пропадает. Я тебе просто говорю, что когда это активно используется в программах проку от твоих универсальных контейнеров — ноль.


kuj>Серьезно, ребят, завязывайте с Delphi. Delphi — зло, оно отупляет.
Ну а ты пальцы гнуть бы завязывал...

Здравствуйте, hattab, Вы писали:


MC>>Вы какие интерфейсы имели в виду? Если COM-интерфейсы (технический аспект) — это одно. Если, скажем так, ООП-интерфейсы (теоретический аспект) — то Вы абсолютно не правы. Рекомендую Вам все же почитать про то, как реализуется сборка мусора в java или .NET (ссылки Вам уже дали).

H>Я читал, спасибо. И раньше еще читал В нативной Delphi тип интерфейсов один -- COM, как вы его называете. Их я и имел ввиду.

Ты уж определись сколько типов интерфейсов есть в Delphi. Не ты ли недавно говорил, что в Delphi интерфейсы могут быть и не COM?

MC>>В Вашем случае с деревом объектов GC сможет выявить, что дерево целиком недоступно — это раз. Далее он в неопределенном порядке выполнит финализаторы объектов, а потом и освободит память. Соответственно, в финализаторах родители и потомки никак не взаимодействуют.

H>Вот (неопределенный порядок, невозможность взаимодействия в финализаторах). Значит тут, и таким способом, задачу не решить. Не смертельно, конечно, но не сильно приятно.

Какая разница в каком порядке они удаляется? Никому от порядка их удаления ни жарко ни холодно. Твоя моя понимать?

Здравствуйте, DOOM, Вы писали:

DOOM открой для себя SOAP, MSMQ, Json.

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, DOOM, Вы писали:

kuj>DOOM открой для себя SOAP, MSMQ, Json.
Ты веточкой не ошибся? К чему ты это написал?

Здравствуйте, DOOM, Вы писали:

H>>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS.
G>>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов?
G>>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов.
DOO>Угу... А какие протоколы обмена используются? А какие порты? А как там с безопасностью?

http://www.rsdn.ru/article/dotnet/inside_remoting1.xml

Автор(ы): Игорь Ткачев
Дата: 11.07.2003
Первая часть статьи, рассказывающая о новой технологии межпроцессной коммуникации — Remoting. Это "родная" для .NET Framework технология, использующая все преимущества платформы. В статье разбираются такие тонкие моменты, как работа с контекстом и перехват создания объектов и вызова методов.

Просвещайся.

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, kuj, Вы писали:

kuj>>1. У Javascript есть нормальный garbage collector. Ему не нужны smart pointer`ы.
DOO>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша.
Не показывай свою необразованность. В C нет обънектов, смарт поинтеры там не нужны.

kuj>>2. Делфи — динамический язык?
DOO>В достаточной мере.
Не более динаический, чем С++. Можно везде писать (void*) и кастить при каждом обращении.

kuj>>А Борланд об этом знает?
DOO>Да уж наверное. Хотя в 6-й дельфи они стали на многие прикольные фишки выдавать ворнинги, что в .Net версии это уже не будет работать.
Наверное ворнинги не от хорошей жизни.

kuj>>Если хочешь посмотреть на динамический язык возьми ruby или python, например.
DOO>Кстати, мое первое впечатление от питона было — о! Дельфи в виде скрипта. Очень много похожего.
У тебя мания делфи

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>>Неужто ты серьезно думаешь, что если есть generic`и, то пропадает возможность кастинга объекта к суперклассу?
DOO>Нет не пропадает. Я тебе просто говорю, что когда это активно используется в программах проку от твоих универсальных контейнеров — ноль.

kuj>>Серьезно, ребят, завязывайте с Delphi. Delphi — зло, оно отупляет.
DOO>Ну а ты пальцы гнуть бы завязывал...
Ты бы завязывал писать глупости

Здравствуйте, DOOM, Вы писали:

kuj>>DOOM открой для себя SOAP, MSMQ, Json.
DOO>Ты веточкой не ошибся? К чему ты это написал?

Не ошибся.

Здравствуйте, hattab, Вы писали:

G>>Если ты имеешь ввиду программситов, которые используют распределенные объекты, то им незнание не мешает.

H>Шедевр

Это называется прозрачная технология. В Delphi о таком только мечтать.

Здравствуйте, Sinclair, Вы писали:

kuj>>>>В C# гораздо больше взято от Java, чем от Object Pascal.
S>Смею предположить, что сие утверждение просто говорит о том, что ты плохо знаешь Object Pascal, и хорошо — Java.
Смею предположить, что сие утверждение просто говорит о том, что ты плохо знаешь Java.

Здравствуйте, _d_m_, Вы писали:

kuj>>В действительности вышеописанных граблей ни в одной нормальной среде разработки быть не должно.

kuj>>Конечно определенные грабли есть везде — где-то меньше, где-то больше. Регулярно пользуюсь VS 2005, VS 2008, пару лет тому назад еще IntelliJ IDEA в арсенале была. Все отлично — на грабли натыкаться не приходиться, работать одно удовольствие.

___>Да есть тоже немножко. Сейчас пользуем VS 2005 SP1:
___>- Если попробовать в док. комментариях добавить для достаточно большого файла
___>/// <summary>
___>/// asda
___>/// </summary>
___>/// <param name="dsda"> asas /</param>
___>вот например в этом месте попытаться напечатать слэш — студия виснет.

Хмм, интересно. На сколько большой должен быть файл, чтоб студия зависла? На .cs в 360kB не виснет и не тормозит... Большего cs-файла под рукой нету...

___>- До SP1 одолевал WinForms дизайнер — открываешь допустим свой контрол, а на нем кнопки съехали. Ну это уже не в счет.

Не сталкивался. Я, правда, с WinForms мало работаю.

___>- WinForms дизайнер — шрифты в дизайнере могут оказаться другого размера, чем на реальной форме.

Это как? Можно сценарий для воспроизведения?

___>- Есть проблемы с дизайнером ReportViewer-а — преобразование единиц измерения, например мм-см, и прочие мелочи типа неверного преобразования margins страницы — это самое неприятное.

Ну это скорее глюк ReportViewer`а?

Здравствуйте, Сергей, Вы писали:

kuj>>Хорошо придумал. В действительности, оптимизация на очень достойном уровне. RTFM вообщем.

С>Я верю, что оптимизация у .NET-компиляторов лучше, чем у Delphi — потому что у нее все совсем уж плохо.
С>Но если сравнить с хорошим оптимизирующим C/C++ компилятором, я думаю, дотнетовский JIT-компилятор проиграет.

Про C++ компиляторы типа Intel C++ спору нет.

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Походу, тут большинство спорщиков "уже отошли".

Многие и не подходили, явно.