Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Потрепаться";
Текущий архив: 2004.10.03;
Скачать: [xml.tar.bz2];

Вниз

Delphi vs. C++   Найти похожие ветки 

 
начинающий ©   (2004-09-05 17:04) [0]

Разговаривал с одним преподавателем по программированию (хотя лучше скзать - по С++). Он утверждает, что у Делфи нет будущего; компиллятор генерит намного более медленный код, чем Визуал С++; Дельфи не годится для больших проэктов (ну, скажем, габариты с MS Office).
Хотя достойно обстоять свою точку зрения он не смог, но, возможно, от этого проблема не исчезла. А что Вы думаете по этому поводу?


 
DrPass ©   (2004-09-05 17:07) [1]

Еще один...
Это у твоего преподавателя нет будущего. Пусть матчасть учит


 
begin...end ©   (2004-09-05 17:09) [2]

Я думаю по этому поводу, что даже если указанные недостатки имеют место, то это не означает, что у Delphi нет будущего. Таким образом, у преподавателя проблемы с логикой. Если это преподаватель по программированию, то, т.к. у него проблемы с логикой, - у него нет будущего.


 
начинающий ©   (2004-09-05 17:12) [3]

А как нащет сабжа? Действительно ли Делфи генерит оччччень медленный код? Или это поклёп?


 
Гаврила ©   (2004-09-05 17:18) [4]

Холи вар...
поклеп
что угодно можно написать на чем угодно
хоть на паскале , ххоть на си
скорость приличная
PS
вреплодаватею скажи что он неправ, если будет возможность


 
YurikGL ©   (2004-09-05 17:20) [5]

Путь на ВизуалАссемблере пишет, если скорости хочет.


 
Gero ©   (2004-09-05 17:20) [6]

Блин, опять...
Не надоело?


 
Игорь Шевченко ©   (2004-09-05 17:27) [7]


> Разговаривал с одним преподавателем по программированию
>


> Хотя достойно обстоять свою точку зрения он не смог


Кто-то из вас врет...


 
SPeller ©   (2004-09-05 17:32) [8]


>  компиллятор генерит намного более медленный код, чем Визуал
> С++;

Да, у VC компилятор сильнее в оптимизациях, но это вовсе не даёт права заявлять что Дельфийский прямо-таки тормоз выдаёт а не код.


> Дельфи не годится для больших проэктов (ну, скажем, габариты
> с MS Office).

У нас на работе на Дельфях написан проект для америкосов, откопилированный ЕХЕ весит 5 метров, прям как апликухи в офисе (всякой графики и прочей фигни в нем мало). А ещё на Дельфях написана бухгалтерская программа, по функциональности примерно 1/3 от 1С. При этом над всем этим (пропорции меняются) работает не более 10 человек программистов. 1-й проект пишем 1 год, второй два года. Первый два месяца назад ушел на внедрение, второй уже год как исправно работает. Так что ваш препод самый обычный сишник приплюсник, фанатик.


 
начинающий ©   (2004-09-05 17:34) [9]

2 Игорь Шевченко:
Врёт? Отчего же? Напр.: когда я спросил привести хоть один везкий аргумент в пользу C++ он ответил, что это язык, наиболее часто используемый при составлениии программ для компов. Меня лично это не убедило.
2 anyone:
Вы бы слышали тон его разговора: как будто я потерял рассудок, а он пытается бросить мне соломинку, которая меня спасет от неминуемого. Еще немного, и похоже, что он начал бы меня оплакивать. Жаль, что я не знаю ни одного более-менее крупного и известного проекта, сотворенного на Дельфи - можно было бы немного его обломать.


 
Ермак ©   (2004-09-05 17:35) [10]

Преимуществ языка C (но не С++!) по сравнению с Паскаль сейчас нет вообще. Скорость +-15% уже давно не является критерием для высокоуровневого программирования. Главное - суметь написать быстрый алгоритм, а уж компилятор - дело десятое...
Зато по ошибкоопасности - С - самый насыщенный язык. На втором месте - С++, на тертьем Visual Basic :-), затем Дельфи, Ява, а самым ошибкобезопасным считается Smalltalk.

Поэтому писать средний прикладной проект на Дельфи лучше всего.

В то же время я не противник, а напротив горячий поклонник С++. Но его стоит применять в задачах, требующих сложного проектирования со множеством взаимосвязей между сущностями. Там ему равных нет. Когда я разрабатывал виртуальную машину под динамический язык, я насчитал десятки моментов, которые нельзя было бы напрямую описать в иерархии классов Дельфи. Множественное наследование, шаблоны и перегрузка операторов - незаменимые вещи для таких задач. В дельфи с их эмуляцией начинается жуткий геморрой, который действительно приводит либо к нечитабельному и нерасширяемому коду, либо к падению быстродействия на порядок (что лучше выбрать - это вопрос, который не даст вам спать спокойно).

Резюме: единственное, но для многих задач огромное, преимущество С++ - возможности проектирования ООП и обощенного программирования (шаблоны).


 
Игорь Шевченко ©   (2004-09-05 17:42) [11]

начинающий ©   (05.09.04 17:34) [9]

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


> что это язык, наиболее часто используемый при составлениии
> программ для компов.


Это действительно так по отношению к паскалю. Хотя бы потому, что число программистов, знающих С (без плюсов) больше.

На самом деле, скорее всего, наибольшее количество программ написано на Basic"е или на Cobol"e.


> Жаль, что я не знаю ни одного более-менее крупного и известного
> проекта, сотворенного на Дельфи


Их есть, и немало. В основном, прикладные.


 
начинающий ©   (2004-09-05 17:46) [12]

Как раз препод. и говорил о том, что Дельфи - для среднячков, а не для профессионалов. Так же было сказано, что ни одна приличная фирма не станет набирать программистов со знанием Дельфи, а то что Дельфи более удобен с точки зрения ошибкобезопасности - ни кого не волнует, и бедным программистам приходится учить то, что надо, а не то что хочется.


 
Ермак ©   (2004-09-05 17:49) [13]

Хороший программист должен знать хотя бы два языка. Дельфи и Си++ - идеальное сочетание.


 
SPeller ©   (2004-09-05 17:51) [14]

То что Си распространённее - у этого языка поддержка очень сильная. Идин мелкософт чего стоит.

Вот писал бы Билл Гейтс изначально на Паскале, был бы сейчас Visual Pascal, а не Visual C++ :)


 
Игорь Шевченко ©   (2004-09-05 18:05) [15]

начинающий ©   (05.09.04 17:46) [12]

Мой совет, смени преподавателя, если возможно. Потому что ламер не сможет научить чему-то.


 
DrPass ©   (2004-09-05 18:46) [16]


> Вот писал бы Билл Гейтс изначально на Паскале

Ты будешь смеяться, но Windows была изначально написана на Паскале. Естественно, на Майкрософтовском, а не Борландовском. И они выпускали довольно передовой компилятор Quick Pascal. А потом стали делить сферы влияния с Борландом, и договорились: Микрософт не посягает на Паскаль, Борланд не посягает на Бейсик (впрочем, это неофициальная версия. И Борланд, и Микрософт упорно хранят молчание о причинах прекращения развития этих линеек компиляторов).
А преподавателя смени - фанатики никогда не были специалистами в программировании


 
начинающий ©   (2004-09-05 19:19) [17]

Игорь Шевченко ©   (05.09.04 18:05) [15]
...ламер не сможет научить...

А какие внешние признаки ламера? Мне кажется, что я еще не вышел ростом, чтобы человека годящегося мне в отцы называть ламером, и бросать в него упрёки в некомпетентности. А может лучше него С++ знает только Страустрап?


 
Nous Mellon ©   (2004-09-05 19:34) [18]

В пятницу тоже такая же ситуация была у меня. Познакомился со своим преподом по программированию. Эх он мне начал втирать :) Столько лапши на ушах я давненько не чувствовал. Сначала он мне сказал что С++ лучший язык. Я молча согласился. С++ и правда хорош чего тут спорить, но я и не собирался с ним спорить. А он расказал мне что Паскаль уже давно умер, потому что был под ДоС. На мое напонимание про Делфи, он ответил, что да, мол, есть такой зверек, но узкий и неказистый и испоьзуюется только малоквалифицированными программистами. Я и тут спорить не стал, а нафига?
Потом он еще рассаказал что Ассемблер никто уже давно не использует и не знает, что NET ничего нового не принесет, что Интел лучшие процессоры и их ГиперТрединг дает на одной машине преимущество в скорости в 50% перед тем же процессором но с ваыключенным HT. Потом пожаловался что у него слабенький проц P4 2.8. На этом я подакав спешно попрощался. Другого и не ждал.


 
Palladin ©   (2004-09-05 19:35) [19]


> А может лучше него С++ знает только Страустрап?

Еслиб это было так, врядли он сделал подобное заявление.


 
Юрий Зотов ©   (2004-09-05 20:36) [20]

> начинающий ©   (05.09.04 17:04)  

> Он утверждает, что у Делфи нет будущего;

Такое говорят с момента появления Delphi. А она все живет, и живет. Видимо, она просто не знает, что у нее нет будущего.

> компиллятор генерит намного более медленный код,
> чем Визуал С++;

Для меня довольно странно, что утверждения подобного рода не сопровождаются конкретными цифрами. Уж кто-то, а преподаватель должен был бы сказать примерно так: "в задачах такого-то класса код медленнее примерно на X процентов, для такого-то класса - на Y процентов, для такого-то класса скорость примерно одинакова, а в среднем код медленнее на Z процентов. Оценки проводились на компьютере таком-то, сравнивались компиляторы таких-то версий, методика сравнения была такой-то."

Когда-то читал статью Криса Касперски, где тоже сравнивались различные компиляторы. Но там сравнение шло вполне конкретное, в каждом тесте оговаривалось, что именно он тестирует, почему он составлен именно так, а не иначе, результаты приводились в виде конкретных цифр. А без всего без этого все заявления подобного рода - пустой звук.

> Дельфи не годится для больших проэктов (ну, скажем, габариты с
> MS Office).

Опять же - хотелось бы знать, почему не годится? Иначе снова получаем голословное (пустословное?) утверждение человека, не знающего предмета, о котором он берется судить.

Сама Delphi, как известно, написана на Delphi - это большой проект? Наш EXE-шник весит более 10 метров (а в исходниках насчитывает порядка миллиона строк) - это большой проект?

> Хотя достойно обстоять свою точку зрения он не смог, но,
> возможно, от этого проблема не исчезла. А что Вы думаете по
> этому поводу?

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

-------------------------------------------------------

P.S.
Чтобы сравнивать компиляторы двух языков, надо, как минимум:
- в совершенстве владеть обоими языками;
- иметь хотя бы представление о том, как устроен компилятор;
- на базе двух предыдущих пунктов разработать методику проведения тестов (для разных задач, языковых конструкций и пр.) - такую, которая была бы объективна и сравнила бы именно компияторы, а не что-то там еще;
- провести сами тесты;
- удостовериться в том, что их результам можно верить.

Иначе получаем примерно вот что:
"Слышал звон, да не знает, где он".
(c) Пословица.


 
Nous Mellon ©   (2004-09-05 20:47) [21]


>
> Такое говорят с момента появления Delphi. А она все живет,
> и живет. Видимо, она просто не знает, что у нее нет будущего.

Давайте не будем ей об этом рассказывать! Пусть остается в неведении и далее :) А то поверит еще во всякую чушь :)


 
KSergey ©   (2004-09-06 08:27) [22]

> [16] DrPass ©   (05.09.04 18:46)
> Ты будешь смеяться, но Windows была изначально написана
> на Паскале.

Мне очень нравится живучесть этой сказки ;))
Уже давно прошли времена упоминания слова pascal в шаблонах функций WinAPI - а сказка упорно живет ;)


 
31512 ©   (2004-09-06 08:54) [23]

Бедные, бедные, несчастные студенты.


 
Мюмзик в мове   (2004-09-06 08:55) [24]

начинающий ©
у Visual С++ есть будущее, пока есть будущее у Windows


 
Rule ©   (2004-09-06 09:04) [25]

Прикольная ветка, которая дала мне толчок вспомнить С, вчастности выучить вижуал С++, хотя я думаю это будет легче чем учить с нуля, так как я знаю синтаксис этого языка и углубленно щас изучаю принципы ООП, по учебнику Буча (кстати учебник таки ориентирован на С++) ...
Спасибо всем, а именно
Юрий Зотов ©   (05.09.04 20:36) [20]
Ермак ©   (05.09.04 17:49) [13]
Хороший программист должен знать хотя бы два языка. Дельфи и Си++ - идеальное сочетание.


Эти посты меня побудили на глубокое изучение С++


 
31512 ©   (2004-09-06 09:32) [26]

Всё это мне напомнило одну забавную ситуацию...
Мне надо было затянуть подшипник один на коробке передач. Я отогнал машину в сервис. Там надо было открутить задний кардан. Мастер берёт специальный гайковёрт (типа дрели какой-то) ставит насадку, откручивает 4 болта... Тратит на это, ну, скажем, 2 минуты (я не засекал). Производит все необходимые действия, закручивает всё на место. Я поездил немного, через некоторое время подшипник опять загремел. Я решил всё сделать сам. Сделал тоже самое, но обычными рожковыми ключами. Пыхтел, пыхтел... Убил на это минут 20. Опять поездил. Подшипник снова гремит. Я поехал на дачу, в деревню. А там есть у меня знакомый мужичок, Володя зовут его. Я прошу ему помочь. Говорю, мол, подшипник гремит, покажи как сделать по человечески. Он (under fly уже с утра) берёт те же рожковые ключи, что и у меня... Вжик, вжик, вжик... Тратит те же, условно,  2 минуты. Показывает, обьясняет, закручивает. Подшипник не гремит до сих пор...
----------------------------------------------------------------
Это я к тому, что от мастерства всё зависит. Инструменты разные, люди разные. Задача одна, а результат может тоже разным может оказаться.
----------------------------------------------------------------
По поводу проектов, написанных на Delphi...
Если я не ошибаюсь это The Bat, Nero... Мало ли их.

С кривыми руками даже на супер-пупер компиляторе делать нечего.
Таково моё скромное мнение...


 
1g0r ©   (2004-09-06 10:54) [27]

Может не совсем в тему, но думаю будет интересен сравнительный анализ компиляторов С++ (Microsoft Visual C++ 6.0, Intel C++ Compiler 4.5, Borland Builder 6.0, MinGW)

ИМХО неплохая такая разборка :)
http://www.cpp.com.ua/?in=kpp_show_article&kpp_art_ID=202&SearchString=компилятор&by_id=3


 
Суслик ©   (2004-09-06 11:10) [28]

У меня был приятель. Мы вместе учились в школе. Во времена появления первых персоналов - xt (персоналки были и раньше, но мы тогда были в начальной школе) он серьезно занимался программирование. Она деж ВО не получил из-за своего пристрастия именно к программированию - паскаль, си, си++, асм и пр. Занимал призовые места на конкурсах "демонстрашка в 16 байт", "демонстрашка в 128" и т.д. Т.е. серьезно знает асм.

Сейчас он полностью ушел от MS - использует только юникс, линукс и пр. Он там является специалистом по безопасности - фактически консультантом. Ездит по всяким международным конференциям - свободный софт, безопасность и т.д.

По его словам и MS c++ и delphi по оптимальности генеренного кода сильно проигрывают c++ под unix (названия производителя не помню). По его словам даже он практически не может ничего ускорить в полученном коде.

Зачем я об этом. Ясный перец, что я в этом не разбираюсь. Просто хотелось привести слова уважаемого мной человека, которые говорят о бесмысленности споров MS C++ vs Delphi.


 
Rem   (2004-09-06 11:11) [29]

[10] >>огромное преимущество С++ - возможности проектирования ООП

А Object Pascal что, инвалид в этом?


 
BorisMor ©   (2004-09-06 11:12) [30]

Пусть препод так не радуется. Скоро(годика 3/4) все перейдут на NET и  всем будет глубоко фиолетово на чем написан твой проект. На VB, VC++, С# или Delphi. Будет работать с более менее одинаковой скоростью + к этому в одном проекте можно будет использовать разные языки. В общем ждем эры коммунизма от Microsoft :)


 
Суслик ©   (2004-09-06 11:16) [31]


> А Object Pascal что, инвалид в этом?

Сейчас Шевченко меня ногами запинает (Юрий Зотов тоже думаю присоединиться), но в java или в C++ реализация ООП мне нравится больше (а чем дальше, тем еще больше :-р))).

Я считаю, что в ООП в указанных языках выше защита от дурака. Т.е. автор классов может лучше управлять возможным использованием классов: если автор не хочет, чтобы класс исползовали определенным образом, то он может проинструктировать компилятор этот момент проконтролировать.

В ООП в дельфи, тоже есть свои преимущества. Но для меня (лично) они не перевешивают недостатки.


 
0d08h   (2004-09-06 11:19) [32]

труба полная С++, Паскаль главное чтоб ты хорошо учился.

Язык программирования только инструмент.


 
wicked ©   (2004-09-06 11:21) [33]


> Может не совсем в тему, но думаю будет интересен сравнительный
> анализ компиляторов С++ (Microsoft Visual C++ 6.0, Intel
> C++ Compiler 4.5, Borland Builder 6.0, MinGW)
>
> ИМХО неплохая такая разборка :)
> http://www.cpp.com.ua/?in=kpp_show_article&kpp_art_ID=202&SearchString=компилятор&by_id=3

очень предвзятая статья с очень спорными утверждениями и выводами....


> По его словам и MS c++ и delphi по оптимальности генеренного
> кода сильно проигрывают c++ под unix (названия производителя
> не помню). По его словам даже он практически не может ничего
> ускорить в полученном коде.

свежо предание... :-/
единственный компилятор, который (опять таки, "в статье прочитал") имеет преимущество на генерации кода с плавающей точкой, так это Intel c++.... про SSE, XMM и прочая умолчим, поскольку это уже различия в самой линейке x86 от разных производителей...


 
KSergey ©   (2004-09-06 11:21) [34]

> [31] Суслик ©   (06.09.04 11:16)

Возможно, это от недопонимания.
Выскажу такую вещь: в С++ единица инкапсуляции - класс, в Delphi - модуль.
А потому сравнивать надо сравнимые вещи.


 
Суслик ©   (2004-09-06 11:27) [35]


> KSergey ©   (06.09.04 11:21) [34]

Ну вот ты еще после ИШ и ЮЗ на мое недопонимание будешь указывать.

Конекретных примеров, чего нельзя в рамках указанного мной выше утверждения нешльзя сделать на Дельфи, а можно на СиПП я приводить не буду. Т.к. обязательно услышу, а зачем (как было раньше). Однако ж утверждение про большую гибкость ООП в сях и джаве не вчера родилось и не спроста: стимулом явилось изучшение ряда литературы, посвященной ООП. Чем больше думаю и пробую, тем больше убеждаюсь в своей субъективной правоте.


 
PVOzerski ©   (2004-09-06 11:30) [36]

IMHO, большинство подобных "критиков" Delphi сами его не юзали. Обидно, что иногда они, кажется, не ламеры. Например, на "Королевстве" один такой, предварительно продемонстрировав наличие определенных знаний в области программирования, вдруг заявил, что Delphi - исключительно средство интеграции компонентов, которые пишутся на Си...


 
Dok_3D ©   (2004-09-06 11:33) [37]

Когда вас можно будет назвать профессиональным программистом?
Тогда, когда вы перестанете участвовать в дискуссиях, посвященных сравнению языков программирования, платформ, операционных систем.

Это я сам только что придумал :)


 
Григорьев Антон ©   (2004-09-06 11:34) [38]

Единственное, чего лично мне не хватает в ООП-модели Delphi - это возможности создания объектов в стеке, чтобы они автоматически освобождались, когда переменная выходит из области видимости. Впрочем, от этого отказываются не только в Delphi, но и в других языках (если не ошибаюсь, в той же Java). Почему - я так и не понял.


 
jack128 ©   (2004-09-06 11:38) [39]

а вот что думает сам Страструп о С++ http://hacknet.spb.ru/html/review/001/03_bjstrous.html :-))


 
Суслик ©   (2004-09-06 11:38) [40]


> Григорьев Антон ©   (06.09.04 11:34) [38]

мне не хватает:
1) друзей классов
2) private конструторов и деструкторов (т.е. никто не может создать и удалить объект - только статический собственный метод).
3) статических переменных.


 
Игорь Шевченко ©   (2004-09-06 11:48) [41]

Григорьев Антон ©   (06.09.04 11:34) [38]


> Единственное, чего лично мне не хватает в ООП-модели Delphi
> - это возможности создания объектов в стеке, чтобы они автоматически
> освобождались, когда переменная выходит из области видимости.


AFAIK, классы, объявленные не через class, а через object позволяют такое. Впрочем, за давностью лет, могу ошибаться.

Суслик ©   (06.09.04 11:27) [35]

У каждого языка свои возможности. Ну и что ?


 
wicked ©   (2004-09-06 11:49) [42]

Григорьев Антон [38] прав, этого ну очень не хватает...
а вот с этим
> чем, от этого отказываются не только в Delphi, но и в других
> языках (если не ошибаюсь, в той же Java)

позвольте не согласиться, поскольку в Java мы можем позволить себе роскошь создавать обьекты, не заботясь об их освобождении - за нас это сделает gc... поэтому, как только ссылка на класс выйдет из области видимости, она тут же попадет в очередь на удаление...

а вот в списке
> 1) друзей классов
> 2) private конструторов и деструкторов (т.е. никто не может
> создать и удалить объект - только статический собственный
> метод).
> 3) статических переменных.

необходим только пункт 2 (если такого нету конечно, поправьте меня)... остальное прекрасно осуществляется таким средством языка, как модуль...

и рискуя быть навязчивым, скажу, что в чем паскаль проигрывает по сравнению с си++, так это в области обобщенного программирования (шаблоны)... ну и до кучи, если поразмыслить, то наличие шаблонов тянет за собой необходимость переопределения операторов...

ЗЫ всё высказанное в этом постинге является имхо"м, и может быть преосмысленно и переоспоренно.... :)


 
Суслик ©   (2004-09-06 11:55) [43]


> Игорь Шевченко ©   (06.09.04 11:48) [41]
> У каждого языка свои возможности. Ну и что ?

Ты сказал, что у каждого языка свои возможности. Ну и что?

Если по сути, то - ничего. Я что-то НЕсубъективно утверждал? Если нет, то какое может быть всем дело до моего субъективного мнения? А высказываться тут вроде никто не запрещал?


 
Думкин ©   (2004-09-06 11:57) [44]


> [43] Суслик ©   (06.09.04 11:55)

Субъективное мнение имеет один недостаток - оно может оказаться не объективным.


 
Суслик ©   (2004-09-06 12:02) [45]


> Субъективное мнение имеет один недостаток - оно может оказаться
> не объективным.

А это недостаток? :))) На то и есть субъективное мнение.
Если я считаю, что мне так лучше - то так лучше. Я же никого не заставляю делать также - я просто поделился мнением.


 
wicked ©   (2004-09-06 12:06) [46]

> Игорь Шевченко ©   (06.09.04 11:48) [41]

> AFAIK, классы, объявленные не через class, а через object
> позволяют такое. Впрочем, за давностью лет, могу ошибаться.

Цитата из справки Delphi 6 (топик Object types, в конце):
Object types are supported for backward compatibility only. Their use is not recommended.

как видим, проблема есть, поскольку единственный способ не рекомендуют...


 
Игорь Шевченко ©   (2004-09-06 12:06) [47]

Суслик ©   (06.09.04 11:55) [43]


> Если по сути, то - ничего.


Если по сути, то не стоит делать далеко идущих выводов о преимуществах объектной модели одного языка над другим.

Насколько я помню, в нашей переписке я указывал способ, как защититься от того дурака, защита от которого в других языках обеспечивается приватными деструкторами.


 
Акуличев Дмитрий   (2004-09-06 12:11) [48]


> Единственное, чего лично мне не хватает в ООП-модели Delphi
> - это возможности создания объектов в стеке, чтобы они автоматически
> освобождались, когда переменная выходит из области видимости.
> Впрочем, от этого отказываются не только в Delphi, но и
> в других языках (если не ошибаюсь, в той же Java). Почему
> - я так и не понял.

Всё с точностью до наоборот, не "от этого отказываются не только в Delphi, но и в других языках", а Ц++ -- чуть ли не единственный язык, где это было.

Отказываются, а точнее, не вводят, по разным причинам. В жабе, например, нет смысла это делать просто потому, что есть автоматическое управление памятью.


 
Суслик ©   (2004-09-06 12:20) [49]


> Игорь Шевченко ©   (06.09.04 12:06) [47]


> Насколько я помню, в нашей переписке я указывал способ,
> как защититься от того дурака, защита от которого в других
> языках обеспечивается приватными деструкторами.


Все же хочу заметить, что во всех своих высказываниях я упоминал термин "компилятор" или глаголы он него.

Способов полно (например, newinstance+freeinstance), но все они будут работать в runtime.
Если интересно, далее могу объяснить, чем runtime плох.

По сути единственный способ предложил ЮЗ - написать эксперта с проверкой кода перед компиляцией.

Никто другой не предложил ( и не может этого сделать ) способа создания private конструктора и деструктора, уровень видимости которых отследживался бы во время компиляции.


 
Акуличев Дмитрий   (2004-09-06 12:23) [50]


> мне не хватает:
> 1) друзей классов

Это не какое-то новое средство Ц++, а вынужденная примочка обхода отсутствия в языке нормальной модульности.
Если этого действительно не хватает (т.е. не хватает НЕДОСТАТКА и костыля для его обхода!), то налицо серьёзные проблемы с постановкой мышления.


> 2) private конструторов и деструкторов (т.е. никто не может
> создать и удалить объект - только статический собственный
> метод).

Ой... А это зачем?


> 3) статических переменных.

Т.е. ещё одного костыля...


 
Суслик ©   (2004-09-06 12:25) [51]

Удалено модератором
Примечание: Offtopic


 
Суслик ©   (2004-09-06 12:26) [52]

Удалено модератором
Примечание: Offtopic


 
Ермак ©   (2004-09-06 12:29) [53]

Может, немного не втему, но... Если уж народ начал сравнивать ООП в языках...
Очень советую посмотреть книжку: Г. Саттер. Решение сложных задач на С++.
Я тоже думал, что ничего осбенного не узнаю, типа, какая разница, на чем писать?
В результате - узнал столько тонкостей об ООП-проектировании, которые даже и в Дельфи оказались полезны. После прочтения класики о С++ (СТрауструп, например, и Саттер) понимаешь, зачем нужен С++. Он не лучше Дельфи, а просто другой. Такой мощности обобщенного программирования нет почти ни в одном языке.


 
Суслик ©   (2004-09-06 12:32) [54]


> Такой мощности обобщенного программирования нет почти ни
> в одном языке.

сейчас получишь на орехи от знатоков.

ЗЫ. Я во многом согласен с тобой в этом высказывании. Чем дальше изучаю с++, тем больше чую в нем именно то, что ты описал.


 
Акуличев Дмитрий   (2004-09-06 12:41) [55]

Удалено модератором
Примечание: Offtopic


 
lipskiy ©   (2004-09-06 12:48) [56]

Господа, правильно ли я понимаю, что каждый язык изначально создавался для решения каких-то определенных типов задач? Иначе как объяснить изобилие языков? А если это так, то для каких конкретных типов задач были изначально задуманы C и Pascal (и их модификации)?


 
Kerk ©   (2004-09-06 12:49) [57]


> Суслик ©   (06.09.04 12:25) [51]

Все же соглашусь с Дмитрием, что friend-классы - это скорее костыль.


 
}|{yk ©   (2004-09-06 12:51) [58]

Тот же Дэвид Парнас говорит, что имено С++ является причиной того, что ООП не стал до сих пор основной парадигмой в программировании. Сложность языка - не показатель его "крутости"


 
pasha_golub (temp)   (2004-09-06 12:51) [59]

Удалено модератором
Примечание: Offtopic


 
Ермак ©   (2004-09-06 12:53) [60]

>>Это не какое-то новое средство Ц++, а вынужденная примочка >>обхода отсутствия в языке нормальной модульности.
>>Если этого действительно не хватает (т.е. не хватает >>НЕДОСТАТКА и костыля для его обхода!), то налицо серьёзные >>проблемы с постановкой мышления.

Позвольте не согласиться. Вся беда в том, что у большинства занкомство с языком С++ начиналась в 90-е годы на Борланд С++, когда еще не было нормального стандарта языка. Если кто не знает: последний полный стандарт С++ - 1998 год. То что раньше - это либо не совсем, либо вообще не С++.

Так вот, в С++ есть полная поддержка модульности. Это простарнства имен (namespaces). И, кстати говоря, очень удобно, что они не привязаны к конкретному файлу, а могут быть раскиданы так, как тебе хочется. То, что я говорил о С++, основывается на реальном опыте решения задачи, решить которую в рамках ООП Дельфи было бы на несколько порядков сложнее. Чего стоит одна невозможность перекрестного подключения модулей! В С++ я знаю, что смогу реализовать ЛЮБУЮ взаимосвязь между сущностями, которую захочу. Но если для конкретной задачи не нужна сложная иерархия сущностей, то я безусловно выбираю Дельфи.


 
wicked ©   (2004-09-06 12:54) [61]

> lipskiy [56]

> Господа, правильно ли я понимаю, что каждый язык изначально
> создавался для решения каких-то определенных типов задач?
> Иначе как объяснить изобилие языков? А если это так, то
> для каких конкретных типов задач были изначально задуманы
> C и Pascal (и их модификации)?

именно pascal задумывался, как язык обучения программированию...
а c задумывался, как заменитель ассемблера (в чём он может конкурировать только с фортом)...
но здесь сравнивать пытаются object pascal и c++ - это не pascal и c...


 
Ega23 ©   (2004-09-06 12:58) [62]

Мда, Holy War....


 
lipskiy ©   (2004-09-06 12:59) [63]


> но здесь сравнивать пытаются object pascal и c++ - это не
> pascal и c...

Это я понимаю, но разве C++ вырос не из С, а object pascal не из pascal?
Причины развития каждого направления - это тоже отдельный вопрос. С чего начинался каждый путь - это одно, и каким путем пошел каждый... путь - это другое, и тоже интересно.
Выходит что оба языка в итоге развились к состоянию, способному решать одни и те же типы задач? Не так ли?


 
Ермак ©   (2004-09-06 13:01) [64]

lipskiy ©   (06.09.04 12:48) [56]
>>Господа, правильно ли я понимаю, что каждый язык изначально >>создавался для решения каких-то определенных типов задач? >>Иначе как объяснить изобилие языков? А если это так, то для >>каких конкретных типов задач были изначально задуманы C и >>Pascal (и их модификации)?

Изначально C - высокоурвневый "ассемблер" для платформы Юникс. Pascal - обучающий язык. Теперь C не нужен почти никому кроме системщиков низкого уровня.

C++ - это не С, это абсолютно другой язык.
Object Pascal - это не Pascal, а язык абсолютно другого уровня.
Хотя общая концепция сохранилась: основная идея Delphi - помочь решить почти любую задачу с минимальными затартами времени. Основная задача С++ - дать возможность решить задачу именно так, как вы сами того хотите, то есть оптимизацией либо по времени написания, либо по расширяемости кода.

>>Тот же Дэвид Парнас говорит, что имено С++ является причиной >>того, что ООП не стал до сих пор основной парадигмой в >>программировании. Сложность языка - не показатель его "крутости"

Между прочим, это так. Эталоном ООП является Smalltalk. Это действительно очень интересный динамический язык, который по быстроте разработки и ошибкобезопасности не имеет себе равных. По многим причинам коммерческого распротсранения не получил. Зато его виртальная машина в сильно обкоцанном виде была использована Sun при разработке Java/


 
pasha_golub (temp)   (2004-09-06 13:01) [65]

А что правда, то что написано в интервью Страуструпа?


 
Акуличев Дмитрий   (2004-09-06 13:02) [66]


> Господа, правильно ли я понимаю, что каждый язык изначально
> создавался для решения каких-то определенных типов задач?

Не правильно. Многие классы задач появились только после появления тех или иных языков. До того эти классы задач просто вообразить было трудно.


> Иначе как объяснить изобилие языков?

Примерно так, как и изобилие видов животных -- эволюцией.


 
Ozone ©   (2004-09-06 13:04) [67]

jack128 ©   (06.09.04 11:38) [39]

И ты в это веришь? Он где-то на своем сайте сам сказал, что это все стебы.


 
lipskiy ©   (2004-09-06 13:07) [68]


> основная идея Delphi - помочь решить почти любую задачу
> с минимальными затартами времени.

Значит я сделал правильный для себя выбор! Это радует.

> > Иначе как объяснить изобилие языков?
>
> Примерно так, как и изобилие видов животных -- эволюцией.

Ясно, везде бардак, хаос, спонтанность...


 
Акуличев Дмитрий   (2004-09-06 13:28) [69]


> Так вот, в С++ есть полная поддержка модульности. Это простарнства
> имен (namespaces). И, кстати говоря, очень удобно, что они
> не привязаны к конкретному файлу, а могут быть раскиданы
> так, как тебе хочется.

А в словарик за словом "модуль" заглянуть?

Нэймспейсы -- это не поддержка (тем более -- ха-ха! -- полная) модульности, это даже не её имитация. Это ещё один костыль при её (модульности) полном отсутсвии. Костыль для обхода одной из проблем, которые возникают, когда программа собирается -- концептуально, я не рассматриваю тут технические ухищрения различных сред (опять костыли!) -- как один большой исходный текст.


> Чего стоит одна невозможность перекрестного подключения
> модулей!

Т.е. опять не хватает недостатка -- свалить всё в один большой исходник.


 
Суслик ©   (2004-09-06 13:45) [70]


> Kerk ©   (06.09.04 12:49) [57]

Соглашаться или нет твое дело.
Я был бы рад, если бы они и в дельфи были.


 
Суслик ©   (2004-09-06 13:50) [71]

холи, не холи, а обвинять в недостатке кого-либо не имея досточно информации, а удалять посты с ответами на головловные обвинения в недостаке чего-либо еще хуже. При этом тот факт, что удаляющий принмает одну из позиций дисскутирующих сторон, совсем портит обсуждение. :((((


 
Ермак ©   (2004-09-06 13:57) [72]

>>Акуличев Дмитрий
Зачем столько эмоций? Еще раз скажу: ЕСТЬ широкий класс задач, в которых перекрестно связанные объекты невозможно хорошо реализовать на Дельфи без тройного а то и более уровня косвенноых ссылок и потери наглядности. Как я буду писать - в виде ли одного большого исходного текста - или каждый намеспасе в отдельном файле - это уже мое дело, а дело среды - предоставить мне как можно больше вариантов.
В простых задачах мое мнение о том, как нужно писать программы, приблизительно совпадает с Борландовским - и я использую Дельфи. В том же случае, если я считаю, что что-то нужно реализовать по другому (напр, через множественное наследование), а среда мне этого не позволяет, я не собираюсь подлаживаться под среду, я просто напишу на том, на чем я могу напрямую воплотить свою концепцию.


 
Суслик ©   (2004-09-06 14:04) [73]


> Ермак ©   (06.09.04 13:57) [72]

Моличи, Илюха - у тебя налицо недостаток мышления. :))

Т.к. у меня тоже недостаток мышления, то не могу полчать: поддерживаю твои высказывания. Особенно вот это "а дело среды - предоставить мне как можно больше вариантов."


 
Romkin ©   (2004-09-06 14:14) [74]

Хм. А кто сказал, что в Борландовском Паскале нет перекрестного подключения модулей?! Типа A uses B и B uses A? Что мешает? Лень в справку по uses глянуть?
Ермак ©  (06.09.04 13:57) [72] Есть множественное наследование в Delphi. Пользуйте интерфейсы. И, на мой взгляд, с интерфейсами это самое наследование гораздо прозрачнее.
Подытоживая, единственное, чего нет в Delphi по сравнению с C++ - это шаблонов. Еще, пожалуй, inline методов.
Все остальное - есть. Аналоги.


 
}|{yk ©   (2004-09-06 14:16) [75]

Да ну, перекрестное подключение в С++ - это такой головняк, какое же это преимущество


 
Суслик ©   (2004-09-06 14:24) [76]


> Romkin ©   (06.09.04 14:14) [74]


> Есть множественное наследование в Delphi

Не надо, не надо - до множественного наследования этой конструкции далеко. Если не ошибаюсь, то, что это не моножественное наслелование сказано в доке по дельфе (или я у Хармона это прочел - не помню).


> Подытоживая, единственное, чего нет в Delphi по сравнению
> с C++ - это шаблонов

Вот видишь, и ты находишь, что в сях есть то что нет в дельфи.
Только вот заметь, что у каждого это "единственное" свое.
Одно предложение: давай каждый будет подитоживать сам, а также решать, что для него единтсвенное.


> Все остальное - есть. Аналоги.

Хи...


 
Суслик ©   (2004-09-06 14:28) [77]


> Суслик ©   (06.09.04 14:24) [76]


> Romkin ©   (06.09.04 14:14) [74]

Про имитацию множественного наследования интерфесами.
Хотел бы добавить, что такую конструкцию можно назвать множественное наследование ИНТЕРФЕЙСА класса, но никак не реализации. Реализацию можно имитировать интерфейсы + делегирование, т.е. когда классы, с которыми непосредственно работает пользователь, ничего не делают сам:
1) реализуют интерфейсы (т.е. смотри на класс с любой стороны)
2) реализацию делегируют. (т.е. запускай меня через любой интерфейс, а я (класс) просто предам твой вызов своему подчиненному объекту).
Но все же это не то - это не множественное наследование.


 
Romkin ©   (2004-09-06 14:29) [78]

И не понимаю я этих войн. Мне на практике не встречались задачи, которые я не мог бы решить с комфортом на Delphi.
Причина, кстати, весьма банальна - Объектный паскаль гораздо проще в изучении, нежели С++. Посмотрите хотя бы на объем Lang Ref :)
Поэтому, увы, в среде программистов на DElphi довольно большая доля, хм, как бы помягче... программистов низкой квалификации. Отсюда и сложилось постепенно мнение, что Delphi - для ламеров, а нормальные пацаны только на сях программируют.
В 96-97 годах была, между прочим, абсолютно обратная ситуация: многие программисты (и хорошие программисты!) перешли с C++ на Delphi. Тогда Delphi была безусловно лучшим инструментом программирования под Windows. И никому в голову не приходило ее хаять или сравнивать с VB или VC ;)
Теперь - отстой и устарело. Во-первых, обидно. Во-вторых, абсолютно несправедливо :))
А в-третьих, через пять лет отстоем будет C# :) К этому идет: простой язык, многое, очень многое взявший от Паскаля. И будут топики, подобные этому, правда, с чем его будут сравнивать - я сказать затрудняюсь. Может, это будет "отстой" по сравнению с C++, может - с Delphi.
Я не берусь гадать. Я не берусь заявлять, что какой-то язык умирает или уже умер. Я просто программирую на том, что мне нравиться. Нравится сейчас, а не через пять лет.


 
Romkin ©   (2004-09-06 14:33) [79]

Суслик ©  (06.09.04 14:28) [77] Пусть. Мне, собственно, пофигу, как называют, лишь бы в печь не ставили. Если что-то, что нельзя назвать множественным наследованием, позволяет тожесамо, что и это самое множественное наследование... И, кстати, прозрачнее :)
То нафиг мне нужно множественное наследование в С++?
Мне, если честно, множественное наследование вообще ни разу не понадобилось :))
>Вот видишь, и ты находишь, что в сях есть то что нет в дельфи.
И что? А в Delphi есть то, чего нет в сях, и что с того?


 
Суслик ©   (2004-09-06 14:33) [80]


> Romkin ©   (06.09.04 14:29) [78]

Да прав ты, кто с тобой спорит.

я тоже на дельфи пишу и вроде никуда не собираюсь.


 
Суслик ©   (2004-09-06 14:35) [81]


> И что? А в Delphi есть то, чего нет в сях, и что с того?

Что? А не надо тогда эмоционально реагировать на такие топики - не понимает он в чем смысл этих войн, и пр.

Есть недостатки - мы их и обсуждаем. Есть достойинства - тоже можно пообсуждать.

Широта взгляда никому не вредила.


 
Суслик ©   (2004-09-06 14:45) [82]


> Если что-то, что нельзя назвать множественным наследованием,
> позволяет тожесамо, что и это самое множественное наследование

Неправда твоя, не тоже самое см. [77].


 
Акуличев Дмитрий   (2004-09-06 14:52) [83]


> Ермак ©   (06.09.04 13:57) [72]
> Зачем столько эмоций?

Это тебе показалось.


> Еще раз скажу: ЕСТЬ широкий класс
> задач, в которых перекрестно связанные объекты невозможно
> хорошо реализовать на Дельфи без тройного а то и более уровня
> косвенноых ссылок и потери наглядности.

Я не верю заклинаниям. Если такой класс задач есть (да ещё и такими большими буквами), тебе не составит большого труда более-менее формально этот класс здесь описать. Или, на худой конец, привести пример.
А мы уж как-нибудь сами разберёмся: действительно ли это такой хитрый класс задач, или всего лишь воплощение в жизнь идеологии "Фигли думать! Трясти надо" (ц) Неизвестный Прапорщик.


> Как я буду писать
> - в виде ли одного большого исходного текста - или каждый
> намеспасе в отдельном файле - это уже мое дело, а дело среды
> - предоставить мне как можно больше вариантов.

Ты за деревьями леса не увидел.
Как раз Ц-среды предоставляют исключительно одну единственную возможсть: строить программу как один большой исходник, маскируя это различными костылями.


 
Ермак ©   (2004-09-06 15:02) [84]

В Дельфи что объект, что интерфейс всегда создается динамически. Это значит, что при работе с ним всегда есть лишний уровень косвенности - обращение через указатель. В С++ статический объект вообще не замедляет работу.

Важно ли это? В большинстве задач - нет. Но для меня было очень важно, когда я писал виртуальную машину для языка программирования (курсовик). Там типы сами являлись переменными, пространства имен - тоже переменными, которые могли создаваться динамически в процессе работы программы, наконец - сама программа - тоже переменная определенного типа, с которой можно работать как с данными. Этакий структурированный Lisp. Так там каждый из классов являлся наследником одновременно двух или нескольких классов, имел множество перекрестных связей. И то, что каждая из этих связей при компиляции превращалась в одну аасемблерную инструкцию, а не в два-три прыжка по цепочке указателей, как в Дельфи, было очень важно.

Если в дйествительности объект является одновременно и тем, и другим (и суп, и мухи одновременно;-), то должна быть возможность явно это указать, а не имитировать через делегирование или интерфейсы.


 
Ермак ©   (2004-09-06 15:09) [85]

to Акуличев Дмитрий:

Попробуй напиши на Дельфи что-либо по типу STL, чтобы любой мог иполучить универсальные контейнеры для любого типа данных, безопасные в плане исключений, и не замедляющие работы по сравнению с необъектным программированием. Когда весь дельфяцкий мир подсядет на твои классы, вместо того чтобы каждый раз писать свой ассоциативный массив, тогда я поверю, что ты можешь жить без "костылей".
Как можно называть костылями возможности языка, которые изначально были заложены в него Страуструпом, вместо того, чтобы использовать не-костыли? Если бы жесткая модульность была такой же гибкой, как пространства имен, почему при созданиии и стандартизации С++ были выбраны "костыли"? С++ - это не надстройка над С, это отдельный язык, и никто не обязывал Страуструпа сохранять совместимость с С. Кстати, в некоторых мометах он ее и не сохранил.


 
Суслик ©   (2004-09-06 15:11) [86]


> Ермак ©   (06.09.04 15:09) [85]

не кипятись.
это же холи вор.
тут нет места доводам :)))


 
SPeller ©   (2004-09-06 15:13) [87]

Поздновато, но скажу про создание объектов в стеке. Игорь Шевченко упомянул object. Да, они это позволяют, но с одним ограничением — память под сам объект освободится, но ни один деструктор при этом не вызовется. Object - это по сути record но с методами. А то что only for backward compatibility — Delphi 7 поддерживает не хуже остальных версий. Про 8-ю ничего не скажу - не пробовал.


 
Ермак ©   (2004-09-06 15:14) [88]

:-) Твоя правда! Я не кипячусь. У меня сравнение с костылями вызвало приступ дикого ржача.


 
Акуличев Дмитрий   (2004-09-06 15:15) [89]


> Суслик ©   (06.09.04 14:28) [77]
> Про имитацию множественного наследования интерфесами.


Интерфейсы -- это не имитация множественного наследования. Это самостоятельная, весьма прозрачная и плодотворная идея.


 
Суслик ©   (2004-09-06 15:16) [90]


> Ермак ©   (06.09.04 15:14) [88]

не надо смеяться - понимаешь каждый, кто знает ООП, думает, что знает его лучше всех. От этого и рождаются обидные слова типа - костыли, недостаток мышления и т.д.


 
Суслик ©   (2004-09-06 15:19) [91]


> Акуличев Дмитрий   (06.09.04 15:15) [89]


> Интерфейсы -- это не имитация множественного наследования

Это не я сказал - это слова Romkin :)))


>Это самостоятельная, весьма прозрачная и плодотворная идея.


Особенно эта идея была бы хороша, если борланд дал бы возможность управлять вызовом/НЕвызовом _addref и _release. Ясно дело, что эти методы можно лишить функиональности (т.е. подсчета ссылок), но это не то.


 
Игорь Шевченко ©   (2004-09-06 15:24) [92]


> Особенно эта идея была бы хороша, если борланд дал бы возможность
> управлять вызовом/НЕвызовом _addref и _release. Ясно дело,
> что эти методы можно лишить функиональности (т.е. подсчета
> ссылок), но это не то.


Чего именно тебе не хватает, что "не то" ?

Желательно с наглядным примером.


 
Serrrrg   (2004-09-06 15:24) [93]

"Немного" критики C/C++

http://burks.brighton.ac.uk/burks/pcinfo/progdocs/cppcrit/


 
Акуличев Дмитрий   (2004-09-06 15:25) [94]


> Ермак ©   (06.09.04 15:09) [85]

При чём тут STL? Ясное дело, что без шаблонов ничего подобного не напишешь. Я против шаблонов, кстати, ничего и не говорил.
Кстати, покажешь мне место в STL, где бы модульность стала помехой?


 
Суслик ©   (2004-09-06 15:29) [95]


> Игорь Шевченко ©   (06.09.04 15:24) [92]


> Чего именно тебе не хватает, что "не то" ?

Конкретный?

Иногда надо, иногда не надо вызывать _release?

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

Убить вызов релиза просто:

 i: ISome;

 i := nil; // не так писать, а
 pointer(i) := nil; // вот так.


Но это же разврат :(((


 
Суслик ©   (2004-09-06 15:30) [96]


> Суслик ©   (06.09.04 15:29) [95]


> Особенно, когда интерфейсы начинают использовать в начале
> проекта, а потом.

заменить на
Особенно, когда интерфейсы начинают использовать НЕ в начале проекта, а потом.


 
Romkin ©   (2004-09-06 15:33) [97]

Суслик ©  (06.09.04 15:29) [95] Ничуть не разврат :)) А не проще дополнительно сделать вызов addref? ;)


 
Суслик ©   (2004-09-06 15:35) [98]


> Romkin ©   (06.09.04 15:33) [97]

конечно можно.
Но я бы больше был рад отмене на уровне компиляции соответсвующих вызовов (например директивами). ПО моему мнению, сложившемуся на основе анализа cpu, это было бы сделать несложно.


 
Ермак ©   (2004-09-06 15:41) [99]

2Акуличев Дмитрий: Ладно, убедил. Коли на шаблоны наездов нет, то и я на модули наезжать не буду. Но вот множественное наследование, ограничения при нем, перегрузка операторов - это извините.

Вообще-то действительно на С++ иногда пожалеешь, что нельзя собрать жесткий модуль вместо размазанных по .h и .cpp пространств имен. Однако иногда удобнее знать наверняка, в каком порядке получит твои файлы компилятор и линковщик. Да и без макроподстановок в Дельфи как без рук.


 
VMcL ©   (2004-09-06 15:42) [100]

>>Суслик ©  (06.09.04 15:35) [98]

Поздно ты. Надо было раньше, пока где-то так Delphi 5 не вышел, написать письмо в Borland с предложением и обоснованием. Могли бы и внять ;)


 
Акуличев Дмитрий   (2004-09-06 15:45) [101]


> Суслик ©   (06.09.04 15:19) [91]
> Особенно эта идея была бы хороша, если борланд дал бы возможность
> управлять вызовом/НЕвызовом _addref и _release. Ясно дело,
> что эти методы можно лишить функиональности (т.е. подсчета
> ссылок), но это не то.

Опять у тебя всё наизнанку вывернуто!
Необходимость явного вызова _addref и _release -- не какая-то крутая фича, а следствие отсутсвия в языке прямой поддержки интерфейсов.


 
Romkin ©   (2004-09-06 15:48) [102]

Суслик ©  (06.09.04 15:35) [98] Тебе подсчет ссылок совсем отключитиь надо? Так не наследуйся от TInterfacedObject :)
Обрати внимание на TVCLCOMObject...
И, наконец, что мешает прямо где нать объявить свои
function _AddRef: Integer; stdcall;
function _Release: Integer; stdcall;
А? Они подцепятся ;)


 
Суслик ©   (2004-09-06 15:48) [103]


> Акуличев Дмитрий   (06.09.04 15:45) [101]

что такое прямая поддержка интерфейсов наверное только таким знатокам как ты известо,

а что это именно фича, а какое-то следствие, тут заливать не надо: возьми cpu, посмотри где и как это вызывается, можно было бы и не вызывать, вот и все.


 
Суслик ©   (2004-09-06 15:49) [104]


> Romkin ©   (06.09.04 15:48) [102]

как же тут все невнимательно читают посты других :)))


 
Суслик ©   (2004-09-06 15:52) [105]


> Romkin ©   (06.09.04 15:48) [102]

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


 
NailMan ©   (2004-09-06 15:58) [106]

Вот вы мне скажите, сильно ли отличается VC от EMVC?

Хочется мне попрограмировать под свой PocketPC(WM2003) и что в качестве учебника нужно?  

ЗЫ: программу хочу с Delphi перевести на покет.

---
WBR, NailMan aka 2:5020/3337.13


 
Игорь Шевченко ©   (2004-09-06 16:05) [107]

Ермак ©   (06.09.04 15:41) [99]


> Да и без макроподстановок в Дельфи как без рук.


Эт еще нафига ?

Суслик ©   (06.09.04 15:29) [95]


> Иногда надо, иногда не надо вызывать _release?
>
> Такое часто возникает при подмесе модели интерфесов с моделью
> объектов. Почти все авторы, кто упоминает интерфейсы в дельфи
> не рекоммендуют так делать. Но все же приходится. Особенно,
> когда интерфейсы начинают использовать не в начале проекта,
> а потом.


То есть, компилятор должен исправлять кривые руки ? Не проще ли выпрямить их ?


> Думаю за пример сойдет.


Нет, не сойдет. Потому что это и не пример вовсе.


 
Anatoly Podgoretsky ©   (2004-09-06 16:08) [108]

Ермак ©   (06.09.04 15:41) [99]
Какой ты сговорчивый :-)


 
Суслик ©   (2004-09-06 16:11) [109]


> Игорь Шевченко ©   (06.09.04 16:05) [107]


> Нет, не сойдет. Потому что это и не пример вовсе.

Игорь, но это ты так думаешь.

------------------
Твоя любмая притча о кривых руках мне (и всем) хорошо известа.
А также то, что ты идеалист. Во многом возможность идеализма является следствием условий работы. Такой подход не у всех возможен. К сожалению.
------------------

Пример все же жизненный и вполне конкретный. Если ты этого не видишь, то опять же могу списать это на твой идеализм.


 
Игорь Шевченко ©   (2004-09-06 16:15) [110]

Суслик ©   (06.09.04 16:11) [109]

Привести пример, который будет более понятен оппоненту никак не получится ?


 
Суслик ©   (2004-09-06 16:22) [111]


> Игорь Шевченко ©   (06.09.04 16:15) [110]

получится:)

1) Вначале был большой проект. Он рос, рос и дорос до того, что стало понятно, что даже в рамках одного проекта надо вводить согическое деление, причем более строгое (т.е. с меньшим количество связей), чем просто public секция объектов.
2) Для этой цели были выбраны интерфесы.
3) Использование инетфейсов было оправдано еще тем, что для визуализации четырех разных конструкций использовался один и тоже набор компонент (гриды, едиты и т.д.).
4) В момент ввода интерфейсов не все конструкции были доделаны.
5) В итоге 2 из четырех мешают объекты и интерфейсы, а 2 сделаны чисто на интерфейсах.
6) Мешание объектов и интерфейсов приводит к тому, что иногда объект создается как объект, потом через as преобразуется к интерфейсу и передается в виз. компонент. Иногда объект сразу созадется как интерфейс. В первом случае подсчет не нужен, во втором нужен. Приходится извращаться, чего легко было бы избежать отменой по месту вызова _release.
7) В настоящее время ведется неспешная работа по отказу подмеса моделей. Когда сделаю, у меня к этой фичи претензий не будет.


 
Dok_3D ©   (2004-09-06 16:22) [112]

Истина где-то рядом. Скоро мы узнаем, у кого толще.


 
Игорь Шевченко ©   (2004-09-06 16:24) [113]


> 7) В настоящее время ведется неспешная работа по отказу
> подмеса моделей. Когда сделаю, у меня к этой фичи претензий
> не будет.


Значит, таки руки, а не свойства объектной модели Object Pascal...


 
Суслик ©   (2004-09-06 16:27) [114]


> Игорь Шевченко ©   (06.09.04 16:24) [113]

я наверное психолог :)))
когда пунт 7 писал гадал через минуту или две Игорь напомнит про руки :))))

Поясняю: данный пунт я привел не для того, чтобы так вот просто выдать свои кривые руки, а для того, чтобы констатировать факт - когда мне ПРИДЕТСЯ отказаться от одной методики (никем, как я сейчас посмотрел, официлально не запрещенной) в пользу другой, язык станет лучше удовлетворять моим потребностям. Но не есть ли это свидетельство некой негибкости?


 
Игорь Шевченко ©   (2004-09-06 16:32) [115]

Суслик ©   (06.09.04 16:27) [114]

А с самого начала писать проект так, чтобы не наступать на грабли, не проще ли ? И в компиляторе ничего менять не надо...

Обычно, о нехватке каких-то средств пишут в borland"овских конференциях, если они действительно требуются. И приводят примеры, как бы требцемые средства помогли решить те или иные проблемы.


 
Суслик ©   (2004-09-06 16:36) [116]


> Игорь Шевченко ©   (06.09.04 16:32) [115]


> А с самого начала писать проект так

Если бы у меня было очень много денег, то я обязательно бы попросил тебя провести проектирование (на полном серьезе). Тогда уверен мы бы не наступили на грабли.

Зачем мне писать на Борланд? Легче другой язык выбрать, предаврительно, его конечно просмотрев на решение старых задач и на минимальное количество новых глюков:)


 
Игорь Шевченко ©   (2004-09-06 16:43) [117]

Суслик ©   (06.09.04 16:36) [116]


> Легче другой язык выбрать


Так там свои проблемы возникнут...


 
Григорьев Антон ©   (2004-09-06 16:51) [118]

Кстати, этот спор - хорошая иллюстрация к идеям Вирта. Он всю жизнь создавал языки, которые вынуждают сначала как можно лучше продумать проект, а потом уж садиться за клавиатуру. И его последний язык, Оберон, в этом отношении ещё требовательнее к качеству проектирования, чем Паскаль, и уж тем более, чем Delphi. А C/C++ создавался с целью наискорейшей реализации всего, что в голову приходит. Получаем закономерный результат: те, кто любит думать в процессе и переделывать проекты, предпочитают C/C++, а те, кто любит заранее всё продумывать - языки линии Паскаля.


 
Игорь Шевченко ©   (2004-09-06 16:52) [119]


> А C/C++ создавался с целью наискорейшей реализации всего,
> что в голову приходит.


А с этого места подробнее...


 
noname_   (2004-09-06 17:06) [120]

2 Romkin [102]

Переопределение _AddRef _Release не всегда помогает.
В следующем примере (получение объекта по интерфейсной ссылке из функции и уничтожение объекта) я не смог избавиться от AV в процедуре DoTest.


program testintf;
{$APPTYPE CONSOLE}

uses
 SysUtils;

type
 ITest = interface(IUnknown)
   procedure Delete;
 end;

 TTest = class(TInterfacedObject, ITest)
 private

 protected
   function _AddRef: Integer; stdcall;
   function _Release: Integer; stdcall;
 public
   procedure Delete;
 end;

var
 gTest: ITest;

procedure TTest.Delete;
begin
 Free;
end;

function TTest._AddRef: Integer;
begin
 Result := -1;
end;

function TTest._Release: Integer;
begin
 Result := -1;
end;

procedure NewObj;
begin
 gTest := TTest.Create;
end;

function GetObj: ITest;
begin
 Result := gTest;
end;

procedure DoTest;
var
 i: Integer;
 s1: string;
begin
 NewObj;
 GetObj.Delete;
 for i := 1 to 500 do
   s1 := StringOfChar(#0, 200000);
end;

begin
 try
   DoTest;
   WriteLn("all right");
 except
   on E: Exception do
     WriteLn(E.Message)
   else
     WriteLn("unknown exception");
 end;
end.


 
Суслик ©   (2004-09-06 17:10) [121]


> noname_   (06.09.04 17:06) [120]

сейчас получишь клеймо "кривые руки".

Вообще в этом случае очень вероятно получить что-нить типа privelaged instructrion. У меня в подобном случае так и было.

Т.е. то, что дельфа лезет в любом случае делать _release меня самого разражало. Я делал так

T: ITest;
T := GetObj;
T.Delete;
Pointer(T) := nil.


 
VMcL ©   (2004-09-06 17:19) [122]

>>Суслик ©  (06.09.04 17:10) [121]

>Т.е. то, что дельфа лезет в любом случае делать _release меня самого разражало.

Странно это слышать. Может ещё и длинные строки компилятору за тебя не разрушать, а вдруг ты чё-то такое этакое с ней заделал?

P.S. Недавно писал одну тулзу на Це-постинкременте. Просто задолбался интерфейсы вручную релизить макросом SAFE_RELEASE. Хотя, в принципе, мне потом подсказали, что можно wrapper"ом было  воспользоваться.


 
Суслик ©   (2004-09-06 17:21) [123]


> VMcL ©   (06.09.04 17:19) [122]

повторю, то, что я сказал ромкину - немнимательно читаете, граждане.

Никто не говорил, про отмену поддержика авт. вызова _release - я говорил про упраление этим процессом.


 
VMcL ©   (2004-09-06 17:30) [124]

>>Суслик ©  (06.09.04 17:21) [123]

Чем тебе не нравится такое управление: Pointer(T) := nil;
?

ИМХО, такая конструкция понятна, причем на уровне обычного понимания операций приведения типов.


 
Суслик ©   (2004-09-06 17:33) [125]


> VMcL ©   (06.09.04 17:30) [124]

Да мне все нравится.
Так и делаю.

В общем-то тема посвящена холи вар. А обязательный вызов _release есть просто одно из того, что я вспомнил на высказываение Акуличева Дмитрий: "Интерфейсы -- это не имитация множественного наследования. Это самостоятельная, весьма прозрачная и плодотворная идея.". Я добавил,что она была бы еще более плодотворной, если ...


 
Григорьев Антон ©   (2004-09-06 17:33) [126]


> Игорь Шевченко ©   (06.09.04 16:52) [119]
>
> > А C/C++ создавался с целью наискорейшей реализации всего,
>
> > что в голову приходит.
>
>
> А с этого места подробнее...


Так автор С (вылетело имя из головы) сам рассказывал, что при создании этого языка он обращал внимание прежде всего на удобство отдельных конструкций, а не на структуру языка в целом. Отсюда такие извращения, как оператор присваивания, возвращающий результат, препроцессор, эквивалентность char и short и т.п. Явно оптимизировались отдельные операции, а не структура программы в целом.


 
Игорь Шевченко ©   (2004-09-06 17:48) [127]


> Так автор С (вылетело имя из головы)


Ричи ?


> сам рассказывал, что
> при создании этого языка он обращал внимание прежде всего
> на удобство отдельных конструкций, а не на структуру языка
> в целом


А нельзя ли источник этого рассказа ?


 
Игорь Шевченко ©   (2004-09-06 17:50) [128]

Григорьев Антон ©   (06.09.04 17:33) [126]

А Страуструпа почитать не помогает (относительно реализации того, что приходит в голову и делания столь поспешных выводов о том, что "кто любит переделывать в проектах и т.д.") ?


 
Verg ©   (2004-09-06 18:02) [129]

Да уж, не на шутку тут у вас... хе-хе...
Мне так только GNU Delphi и не хватает.
Кросс, embedded, и проч. "удвольствия" Борланд решил навсегда обойти стороной. Обидно. Ну, впрочем,ему же и хуже...


 
Акуличев Дмитрий   (2004-09-06 18:05) [130]


> Суслик ©   (06.09.04 17:33) [125]
> В общем-то тема посвящена холи вар. А обязательный вызов
> _release есть просто одно из того, что я вспомнил на высказываение
> Акуличева Дмитрий: "Интерфейсы -- это не имитация множественного
> наследования. Это самостоятельная, весьма прозрачная и плодотворная
> идея.". Я добавил,что она была бы еще более плодотворной,
> если ...

Если бы перед тем, как спороть чушь, ты бы ещё задумывался...

Интерфейс -- это не объект, это предоставляемый объектом сервис, возможно, один из нескольких. Отсюда первое следствие: время жизни интерфейса не совпадает со временем жизни объекта. Задумывался над вопросом: почему при возможности реализации многих интерфейсов в одном объекте интерфейсы имеют независимые средства управления числом ссылок?
Второе следствие: интерфейс не может содержать методов разрушения объекта целиком.

В общем, как говорил дедушка Крылов: "У ламера всегда компилер виноват".


 
Григорьев Антон ©   (2004-09-06 18:10) [131]


> Игорь Шевченко ©   (06.09.04 17:48) [127]
>
> > Так автор С (вылетело имя из головы)
>
> Ричи ?
>
> А нельзя ли источник этого рассказа ?


Да, Ричи, спасибо. А источник попробую поискать, так не помню, где я это читал. Помнил бы - сразу бы привёл ссылку :)


> Игорь Шевченко ©   (06.09.04 17:50) [128]
> А Страуструпа почитать не помогает (относительно реализации
> того, что приходит в голову и делания столь поспешных выводов
> о том, что "кто любит переделывать в проектах и т.д.") ?

Согласен с тем, что в C++ есть средства, позволяющие грамотно проектировать приложения, но одновременно есть и такие средства (в основном, унаследованные из C), которые позволяют без этого проектирования обойтись.

Честно говоря, я думаю, что если бы Страуструп создавал свой язык с нуля, а не основывался бы на С, получился бы куда как более приятный язык. Потому что наличие многих хороших безопасных конструкций в С++ соседствует с необязательностью их использования. Пример - есть константы и шаблоны, но нет запрета на использование для аналогичных целей препроцессора. Или - новые более безопасные операторы приведения типов не отменяют традиционного С-шного способа.


 
Акуличев Дмитрий   (2004-09-06 18:15) [132]


> Честно говоря, я думаю, что если бы Страуструп создавал
> свой язык с нуля, а не основывался бы на С, получился бы

Получился бы Оберон.

Впрочем, нет, не получился бы. Страуструп уже был отравлен ядом Ц.


 
Verg ©   (2004-09-06 18:21) [133]


> В общем, как говорил дедушка Крылов: "У ламера всегда компилер
> виноват".


А плохому сисадмину - Windows.


 
Суслик ©   (2004-09-06 18:22) [134]


> Акуличев Дмитрий   (06.09.04 18:05) [130]

Резок ты, Димон, в оценках.
Каюсь, у меня нет времени свою чушь делать столь выразительной посредством bold шрифта, а вот у тебя свою - есть.
Похвально.


> Отсюда первое следствие: время жизни интерфейса не совпадает
> со временем жизни объекта

откуда ты вывел эту мягко говоря фигню?
Сам придумал? Книжечек умненьких начитался. :))) Это проходит, когда сам думать начнешь.


 
Суслик ©   (2004-09-06 18:23) [135]

Удалено модератором


 
Игорь Шевченко ©   (2004-09-06 18:25) [136]

Суслик ©   (06.09.04 18:22) [134]


> откуда ты вывел эту мягко говоря фигню?
> Сам придумал? Книжечек умненьких начитался. :))) Это проходит,
> когда сам думать начнешь.


Дима, прежде чем ламерить, изучи матчасть.


 
Verg ©   (2004-09-06 18:28) [137]

Да уж, колбасит что-то не по-детски.
А вы с тупого конца не пробовали? ..ну,.. в смысле яйца бить?


 
Суслик ©   (2004-09-06 18:29) [138]


> Игорь Шевченко ©   (06.09.04 18:25) [136]

Быстро работаешь (135).

Игорь. Понятие интерфейса меняется от одной объектной нотации к другой. Как минимум я видел два. В дельфи есть реализация ключевого слова interface. Утверждение многоуважаемого Дмитрия:
"Отсюда первое следствие: время жизни интерфейса не совпадает со временем жизни объекта" не соответствует семантике ключевого слова interface. Мне удивительно с каких таких позиций ты утверждаешь обратное? Уверен, что не с тех, которые ты обозначил в [136] в отношении меня. Тогда с каких?


 
Суслик ©   (2004-09-06 18:30) [139]


> Verg ©   (06.09.04 18:28) [137]

согласен, съезд на личности тянет.

Ты заметь - кто начала употреблять слова:
1 ламер
2 чушь
3 недостаток мышления


 
GrayFace ©   (2004-09-06 18:37) [140]

Ермак ©   (05.09.04 17:35) [10]
Преимуществ языка C (но не С++!) по сравнению с Паскаль сейчас нет вообще.

Как бы не так. Одни { } вместо begin end чего стоят. А еще хороший for, еще a:=?b:c:d; т.е. болбшие удобства. А как в паскале указатели сделаны - это же ужас!
Скорость +-15% уже давно не является критерием для высокоуровневого программирования.
Еще как является, но реально, ИМХО, там +-5% от силы.
Поэтому писать средний прикладной проект на Дельфи лучше всего.
Не по этому. Все дело в возможностях.

Игорь Шевченко ©   (05.09.04 17:42) [11]
На самом деле, скорее всего, наибольшее количество программ написано на Basic"е или на Cobol"e.

А что такое Cabol? На Basic - это да. Только треть программ на Basic"е - это рисоваание машинки и т.п(возможно даже едущей), другая треть - вычисление факториала и т.п., а третья - это проги для Емахи и т.д.

начинающий ©   (05.09.04 17:46) [12]
Так же было сказано, что ни одна приличная фирма не станет набирать программистов со знанием Дельфи

Просто чушь.

Игорь Шевченко ©   (05.09.04 18:05) [15]
Мой совет, смени преподавателя, если возможно. Потому что ламер не сможет научить чему-то.
Не все самодуры - ламеры, но самодур тоже многому не научит.

Юрий Зотов ©   (05.09.04 20:36) [20]
Нееет. Нормальный препод скорее бы сказал так: "Такой-то код превращается в такой-то ассемблерный код", либо "То-то код оптимизируется хуже", либо "с объектами работа медленнее", но
a) Зачем даказывать все, что говоришь - спросят - докажешь.
b) Препод мог прочесть статью уважаемого им человека, не запомнив примеры
c) Ученик может не знать ни асма, ни объектов

Мюмзик в мове   (06.09.04 8:55) [24]
у Visual С++ есть будущее, пока есть будущее у Windows

Думаешь, заката Visual C++ мы не застаним? Или думаешь, что Windows вот-вот уйдет? Я думаю, что Visual C++ еще лет 10-20 прожевет, а Windows - гораздо дольше. Хотя, Microsoft, может быть, сменит название Windows...

Ермак ©   (05.09.04 17:49) [13]
Хороший программист должен знать хотя бы два языка. Дельфи и Си++ - идеальное сочетание.

Я знаю Delphi и Pascal :) Хотя еще чуть-чуть Асм, Java и сишный синтаксис. А Basic уже не знаю.

Rem   (06.09.04 11:11) [29]
[10] >>огромное преимущество С++ - возможности проектирования ООП
А Object Pascal что, инвалид в этом?


Именно инвалид. Интерфейсы - полезная штука ,а в Delphi  - это геморрой тот еще, особенно то, что по интерфейсу не возможно узнать объект (могу ошибаться). +Переопределение операций.
Это абсолютно ИМХО.

PVOzerski ©   (06.09.04 11:30) [36]
LOL

Игорь Шевченко ©   (06.09.04 11:48) [41]
У каждого языка свои возможности. Ну и что ?

Думкин ©   (06.09.04 11:57) [44]
Субъективное мнение имеет один недостаток - оно может оказаться не объективным.


Извините, но это чистая демогогия.

wicked ©   (06.09.04 12:54) [61]
но здесь сравнивать пытаются object pascal и c++ - это не pascal и c...

Как я понимаю, Delphi - это object pascal + оболочка + VCL т.д. Здесь сравнивают именно Дельфи и C++, а сам Object Pascal - ИМХО, жалкое подобие языка C++.

lipskiy ©   (06.09.04 12:59) [63]
Выходит что оба языка в итоге развились к состоянию, способному решать одни и те же типы задач? Не так ли?

См. Ермак [60] - это одно из немногих отличий областей применения.

jack128 ©   (06.09.04 11:38) [39] - нельзя верить хотя бы по тому, что это опубликованно на сайте со словом "hack" в названии. Как подсказывает мой скромный опыт, на сахтах по хаку часто бывают завирусованные программы, очень часто всплывающие окна, а уж о достоверности информации и говорить не чего. А жаль.

Акуличев Дмитрий   (06.09.04 13:28) [69]
Нэймспейсы -- это не поддержка (тем более -- ха-ха! -- полная) модульности, это даже не её имитация. Это ещё один костыль при её (модульности) полном отсутсвии.
А хоть один аргумент в защиту своих слов?

Romkin ©   (06.09.04 14:29) [78]
И никому в голову не приходило ее хаять или сравнивать с VB или VC ;)

Ну с VB сравнивать - это кощунство.
C# :) К этому идет: простой язык, многое, очень многое взявший от Паскаля.
Например?
Romkin ©   (06.09.04 14:33) [79]
Если что-то, что нельзя назвать множественным наследованием, позволяет тожесамо, что и это самое множественное наследование... И, кстати, прозрачнее :)

И, кстати, геморройнее. :o)

Суслик ©   (06.09.04 14:33) [80]
Да прав ты, кто с тобой спорит.

Я. И я считаю, что он не прав.

Акуличев Дмитрий   (06.09.04 15:15) [89]
Интерфейсы -- это не имитация множественного наследования. Это самостоятельная, весьма прозрачная и плодотворная идея.

Хоть в чем-то ты прав.


 
Игорь Шевченко ©   (2004-09-06 18:40) [141]

GrayFace ©   (06.09.04 18:37) [140]


> А как в паскале указатели сделаны - это же ужас!


"Видел я код этого ворда - кто ж так пишет" (с)

Что именно ужасного в указателях в паскале ?


 
Verg ©   (2004-09-06 18:52) [142]

"А вы все еще не пробовали сделать серьезный проект на ADA?" (C) Один умолишенный из госпиталя МО США.


 
Акуличев Дмитрий   (2004-09-06 18:57) [143]

Удалено модератором


 
Sergey Kaminski ©   (2004-09-06 19:04) [144]

^^^^^
:)
Теперь я знаю, через какой TInterface реализуется DiamondShark


 
Verg ©   (2004-09-06 19:05) [145]

Брэк!!!

Вот сколько я на своей памяти такого сорта споров помню, все они заканчивались примерно одночленно...
:)))... грязной руганью...


 
Agent13 ©   (2004-09-06 19:05) [146]


> "А вы все еще не пробовали сделать серьезный проект на ADA?"

...
Тогда мы идём к вам??? :)


 
Ермак ©   (2004-09-06 19:09) [147]

>>Григорьев Антон ©   (06.09.04 16:51) [118]
>>Кстати, этот спор - хорошая иллюстрация к идеям Вирта. Он всю >>жизнь создавал языки, которые вынуждают сначала как можно >>лучше продумать проект, а потом уж садиться за клавиатуру....

Вполне согласен. А вот про Оберон можно чуть подробнее? Що це такэ и с чем его ядят?


 
Акуличев Дмитрий   (2004-09-06 19:17) [148]


> GrayFace ©   (06.09.04 18:37) [140]


>> Нэймспейсы -- это не поддержка (тем более -- ха-ха! -- полная)
>> модульности, это даже не её имитация. Это ещё один костыль
>> при её (модульности) полном отсутсвии.

> А хоть один аргумент в защиту своих слов?

Во-первых, ответ уже содержится в этой ветке, во-вторых, я предлагал словарик почитать.

Модуль -- единица инкапсуляции. Нэймспейс -- нет.


> Именно инвалид. Интерфейсы - полезная штука ,а в Delphi
>  - это геморрой тот еще, особенно то, что по интерфейсу
> не возможно узнать объект (могу ошибаться). +Переопределение
> операций.
> Это абсолютно ИМХО.

Это абсолютно кю.
Геморрой начинается там, где кончается понимание.

А вот переопределение операций -- действительно геморрой.


 
Суслик ©   (2004-09-06 19:22) [149]

Удалено модератором


 
Суслик ©   (2004-09-06 19:23) [150]


> Sergey Kaminski ©   (06.09.04 19:04) [144]

А может это DimondShark и есть?


 
Суслик ©   (2004-09-06 19:24) [151]

Удалено модератором


 
Ермак ©   (2004-09-06 19:25) [152]

>> А вот переопределение операций -- действительно геморрой.

Ой ли? Никто не заставляет человека это использовать, но в некоторых случаях это очень удобно. Тогда в Дельфи, например, тип PChar и любой другой, написанный уже вами, а не Борланд,мог бы иметь семантику такую же, как и String, и достаточно было бы заменить Type string на Type MyString чтобы вся программа начала работать со строками другого формата. А уж кем эти строки реализованы ей бы было глубоко параллельно. Это, конечно, не очень хороший пример, но суть ясна...


 
Суслик ©   (2004-09-06 19:26) [153]

Удалено модератором


 
Ермак ©   (2004-09-06 19:29) [154]

Удалено модератором


 
Суслик ©   (2004-09-06 19:29) [155]

Удалено модератором


 
Ермак ©   (2004-09-06 19:31) [156]

Народ, а все таки: ЧТО ТАКОЕ ОБЕРОН? А то скажет кто-нибудь умное слово, а чтоб объяснить дураку, так это нет!


 
Суслик ©   (2004-09-06 19:32) [157]


> Ермак ©   (06.09.04 19:29) [154]

Понимешь ли в чем дело...

Люли прочтя много книг по ООП начинаю считать себя очень умными. Скорее всего так и есть (даже точно так и есть), но они совершенно перестают слушать чужое мнение - фигли я столько читал и думал (и, возможно, учил наиузусть), чтобы принимать чужое мнение.

Само по себе это явление неискоренимо - образованные не слушают образовывающихся. Это не только в прогрммировании, это везде :(


 
Акуличев Дмитрий   (2004-09-06 19:33) [158]


> Ермак ©   (06.09.04 19:25) [152]

Дело в том, что переопределённая операция может прийти со стороны (вспомним, что собирается у нас программа фактически как один большой исходник). И вот тут начинаются чудеса, когда при включении какого-то левого .h вруг меняется семантика уже написанного (причём, возможно, что и не твоего, а опять же стороннего!) кода.

Сравнение с совместимостью разных типов строк не совсем корректно. Эти операции являются частью спецификации языка, они описаны, и они не меняются со стороны.


 
Суслик ©   (2004-09-06 19:35) [159]

Удалено модератором


 
Акуличев Дмитрий   (2004-09-06 19:40) [160]


> Ермак ©   (06.09.04 19:31) [156]
> Народ, а все таки: ЧТО ТАКОЕ ОБЕРОН?


http://www.oberon.ethz.ch/


 
jack128 ©   (2004-09-06 19:41) [161]

Ozone ©   (06.09.04 13:04) [67]
GrayFace ©   (06.09.04 18:37) [140]
Ребят, вы смайлики замечаете?? Я вообще эту ссылку на форуме Юмор на rsdn подобрал..

Ермак ©   (06.09.04 19:31) [156]
Язык Вирта. на Королевстве огромный флейм ему посвещен..

> Суслик ©  
на счет времени жизни интерфейсов..

 TSimpleIntfObject = class(TObject, IUnknown)
 protected
   { IUnknown }
   function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
   function _AddRef: Integer; stdcall;
   function _Release: Integer; stdcall;
 end;

function TSimpleIntfObject._AddRef: Integer;
begin
 Result := -1;
end;

function TSimpleIntfObject._Release: Integer;
begin
 Result := -1;
end;

function TSimpleIntfObject.QueryInterface(const IID: TGUID;
 out Obj): HResult;
const
 E_NOINTERFACE = HResult($80004002);
begin
 if GetInterface(IID, Obj) then Result := 0 else Result := E_NOINTERFACE;
end;

var
 obj: TSimpleIntfObject;
 intf: IUnknown;
begin
 obj := TSimpleIntfObject;
 obj.GetInterface(IUnknown, intf);
end; // интерфейс помер, а объект живет..


 
GrayFace ©   (2004-09-06 19:44) [162]

Игорь Шевченко ©   (06.09.04 16:05) [107]
> Да и без макроподстановок в Дельфи как без рук.
Эт еще нафига ?

Для return, например. Без него тяжко.

Суслик ©   (06.09.04 16:11) [109]
А также то, что ты идеалист.

Это точно.

Игорь Шевченко ©   (06.09.04 16:32) [115]
А с самого начала писать проект так, чтобы не наступать на грабли, не проще ли ? И в компиляторе ничего менять не надо...

Не все программисты идеальны. Не все ХОРОШИЕ программисты идеальны - и у них бывают ошибки в проектировке.

Григорьев Антон ©   (06.09.04 16:51) [118]
Не выворачивай все наизнанку. Delphi создавался для того, чтобы программисты вообще не думали. В нем просто меньше возможностей объектного программирования, поэтому в нем сложна переделка программ. Но, по уму, в C++ желательно проектировать не меньше.

Игорь Шевченко ©   (06.09.04 18:40) [141]
Что именно ужасного в указателях в паскале ?

К ним ничего нельзя прибавить. Единственный способ - inc, но в выражениях он не работает.

Verg ©   (06.09.04 19:05) [145]
На моей памяти это 3 случай после DiamondShark и ветки на Дремучих о взломанности этого сайта. Рулят такие обсуждения, ИМХО, даже не знаю, почему.

Акуличев Дмитрий   (06.09.04 19:17) [148]
Во-первых, ответ уже содержится в этой ветке, во-вторых, я предлагал словарик почитать.

Я ветку читал. Ответ нету. Все твои слова на эту тему - это че-то типа "это так и если вы утверждаете обратное (хаха), то это так, как я сказал".
Модуль -- единица инкапсуляции. Нэймспейс -- нет.
И что? Ну не удобно же все лепить в один модуль. Namespace - ед. инкапсуляции, модуль - частный случай Namesapace.

>Это абсолютно кю.
> Геморрой начинается там, где кончается понимание.

Интерфейсов по-нормальному зделана в Java - там это вообще не сущьность, а как-бы класс объекта, но без методов. COM-интерфейсы для таких нужд мало пригодны, а множественное наследование - очень даже.

А вот переопределение операций -- действительно геморрой.
Так, как это сделано в C++ - да, согласен.

Ермак ©   (06.09.04 19:25) [152]
Ой ли? Никто не заставляет человека это использовать, но в некоторых случаях это очень удобно.
А если юзеру приспичит одному объекту присвоить другой по значению?


 
vuk ©   (2004-09-06 19:48) [163]

to Суслик:
Зря так на Акуличева. Он может немного и резко высказался, но во всем прав.

to GrayFace ©   (06.09.04 19:44) [162]:
>Namespace - ед. инкапсуляции, модуль - частный случай
>Namesapace.
В C++ Namespace - не единица инкапсуляции, а средство борьбы с конфликтами имен в больших программных комплексах. Придумано исключительно из-за отсутствия модульности, т.к. при наличии этой самой модульности пространства имен в понимании C++ нафиг не нужны.


 
Суслик ©   (2004-09-06 19:48) [164]


> GrayFace ©   (06.09.04 19:44) [162]


> Что именно ужасного в указателях в паскале ?
> К ним ничего нельзя прибавить. Единственный способ - inc,
> но в выражениях он не работает.


Ты не прав - приобразуй к integter и прибавляй, затем к pointer

pointer(Integer(p) + 1)


 
GrayFace ©   (2004-09-06 19:49) [165]


> Но, по уму, в C++ желательно проектировать не меньше.

В смысле, предварительно.

> а множественное наследование - очень даже.

ИМХО, множественное наследование - это круто. Зря его заменили интерфейсы. Но все мои слова о C++ - это очень ИМХО... я на нем не програмировал, но от отца наслышан.


 
Ермак ©   (2004-09-06 19:50) [166]

>А если юзеру приспичит одному объекту присвоить другой по значению?

А запретить кто мешает? Приватным-то переопределнием операции?


 
GrayFace ©   (2004-09-06 19:52) [167]

Суслик ©   (06.09.04 19:48) [164]
Ты не прав - приобразуй к integter и прибавляй, затем к pointer

pointer(Integer(p) + 1)


Так и приходится. Но это как begin end - хлам, загромождающий программу. Уменьшает читабильность(begin end кому-то читабильность, может, и увеличивает), заставляет писать море лишних слов.


 
vuk ©   (2004-09-06 19:58) [168]

to GrayFace ©   (06.09.04 19:52) [167]:
>Так и приходится.
Пишите PChar вместо Pointer и будет Вам щщщщастье.


 
Суслик ©   (2004-09-06 19:59) [169]

Удалено модератором


 
GrayFace ©   (2004-09-06 20:00) [170]

vuk ©   (06.09.04 19:58) [168]
Спасибо. Буду использовать. Вот только к PInt все-равно ничего не прибавить.


 
Суслик ©   (2004-09-06 20:00) [171]

Я вообще первый раз участвую в ХОЛИ ВОР.

Они всегда так заканчиваются?


 
vuk ©   (2004-09-06 20:01) [172]

to Суслик ©   (06.09.04 19:59) [169]:
>Его манера высказываться не располагает
>меня к нормальной беседе.
Можно манеру игнорировать, но следить за смыслом. :o) А со смыслом там все OK. И по времени жизни интерфейсов - тоже.


 
GrayFace ©   (2004-09-06 20:01) [173]

vuk ©   (06.09.04 19:48) [163]
Зря так на Акуличева. Он может немного и резко высказался, но во всем прав.

8-0


 
Суслик ©   (2004-09-06 20:01) [174]


> GrayFace ©   (06.09.04 20:00) [170]

Может и не надо ничего прибавлять?
Средства в дельфи есть, а т.к. согласись операция не настолько частая, то их (средств) вполне достаточно. ИМХО.


 
Sergey Kaminski ©   (2004-09-06 20:02) [175]

>> Они всегда так заканчиваются?

Да, они начинаются и заканчиваются всегда одинаково. Все расходятся по углам, надувшись. И так до следующего раза.


 
Суслик ©   (2004-09-06 20:03) [176]


> vuk ©   (06.09.04 20:01) [172]

Про время жизни, согласен.
Понимаешь там на каком то этапе ИШ подключился. Он уважаем разные нотации записи ООП. Я что-то переключился на бучевствое определение интерфейса. Бывает...


 
Суслик ©   (2004-09-06 20:04) [177]


> Sergey Kaminski ©   (06.09.04 20:02) [175]


> Да, они начинаются и заканчиваются всегда одинаково. Все
> расходятся по углам, надувшись. И так до следующего раза.

Жаль...
Я бы очень хотел пообщаться с вменяемым человеком на предмет обсуждения Дельфи и Си.


 
GrayFace ©   (2004-09-06 20:04) [178]

Суслик ©   (06.09.04 20:01) [174]
Нет. Это неудобство, ничем не обоснованное. Я люблю работать с указателями, тем более, это очень сильно увеличивает скорость.


 
uny   (2004-09-06 20:05) [179]

ну а кто виноват - впечатлительный или его препод?


 
Суслик ©   (2004-09-06 20:06) [180]

Удалено модератором


 
Акуличев Дмитрий   (2004-09-06 20:08) [181]


> GrayFace ©   (06.09.04 19:52) [167]
> Суслик ©   (06.09.04 19:48) [164]
> Ты не прав - приобразуй к integter и прибавляй, затем к
> pointer
>
> pointer(Integer(p) + 1)
>
> Так и приходится. Но это как begin end - хлам, загромождающий
> программу. Уменьшает читабильность(begin end кому-то читабильность,
> может, и увеличивает), заставляет писать море лишних слов.

А с чего это вдруг у тебя в программе такие операции появляются?


 
Суслик ©   (2004-09-06 20:08) [182]


> GrayFace ©   (06.09.04 20:04) [178]

Если ты пользуешься ansi строками, дин массивами и штатным манагером памяти обсолютно для всех целей, то о скорости говорить не приходится. Выигрышь в прибавлении чисел к поинтерам будет мал.

И даже не имхо.


 
Ермак ©   (2004-09-06 20:11) [183]

Удалено модератором


 
jack128 ©   (2004-09-06 20:13) [184]

Суслик ©   (06.09.04 20:08) [182]
Если ты пользуешься ansi строками, дин массивами и штатным манагером памяти обсолютно для всех целей, то о скорости говорить не приходится. Выигрышь в прибавлении чисел к поинтерам будет мал.


Вообще то штатный менеджер памяти как раз увеличевает производительность приложения. Так что на его фоне выигрыш будет белее заметен, чем при использовании виндовых функции аллокации памяти...


 
Ермак ©   (2004-09-06 20:15) [185]

>>А с чего это вдруг у тебя в программе такие операции появляются?

А почему бы им не появляться? В коде, который должен быстро работать с тесктом, только ламер будет работать со стрингами, в другом случае - постоянно гоняешь PChar(string), и наоборот. И pointer++ -- - на каждом шагу.


 
Суслик ©   (2004-09-06 20:15) [186]


> Ермак ©   (06.09.04 20:11) [183]
> Игнорировать?
>
> Вообще-то такие места, натипа, удушу и т.п. обычно модерами
> вырезаются. Тогда можно их игнорировать сколько угодно...

Хе...


>
> Вообще то штатный менеджер памяти как раз увеличевает производительность
> приложения. Так что на его фоне выигрыш будет белее заметен,
> чем при использовании виндовых функции аллокации памяти...

В данном случае ты не совсем прав. Есть еще виртуальная память.
В случае целевого еще использования (например, хранить млн блоков по 1024 байт ибольше ничего) производительность можно очено поднять. Проверял.


 
vuk ©   (2004-09-06 20:18) [187]

to Суслик ©   (06.09.04 20:06) [180]:
>К тебе сложно придаться - мало говоришь.
Ну дык. Золотое правило: молчи - за умного сойдешь. Вот я и стараюсь. :o)

>Но может когда нить найду и сразу в карьер
You"re welcome! :o)


 
Суслик ©   (2004-09-06 20:18) [188]


> jack128 ©   (06.09.04 20:13) [184]

Ты попробуй помучать дома штатный манагер:
1) создавать/удалять строки случайной длинны
2) созадвать/удалять блоки по 123 (например) байт.

Попробуй тоже самое написать для виртуальной памяти. Разница будет. Как по скорости, так и по оптимальности хранения. На каждый блок ты сможешь тратить менее 4 байт, как в штатном манагере.


 
Ермак ©   (2004-09-06 20:18) [189]

>>В данном случае ты не совсем прав. Есть еще виртуальная память.
>>В случае целевого еще использования (например, хранить млн >>блоков по 1024 байт ибольше ничего) производительность можно >>очено поднять. Проверял.

Если работаем с кусками больше чем пол-мега, надо использовать виндовские функции для резервирования страниц памяти. А иногда - mapped-files.


 
Суслик ©   (2004-09-06 20:19) [190]

Удалено модератором


 
Суслик ©   (2004-09-06 20:20) [191]


Ермак ©   (06.09.04 20:18) [189]
Если работаем с кусками больше чем пол-мега, надо использовать виндовские функции для резервирования страниц памяти

я же вроде говорил про виртуальную память?
Ты имеешь в виду другие страницы? Это что?


 
Акуличев Дмитрий   (2004-09-06 20:22) [192]


> Ермак ©   (06.09.04 20:15) [185]
> >>А с чего это вдруг у тебя в программе такие операции появляются?
>
> А почему бы им не появляться? В коде, который должен быстро
> работать с тесктом, только ламер будет работать со стрингами,
> в другом случае - постоянно гоняешь PChar(string), и наоборот.
> И pointer++ -- - на каждом шагу.

А для PChar как раз реализована адресная арифметика, работает и P+123, и inc(P), и P[i].

Меня больше необходимость этого для других типов интересует.


 
jack128 ©   (2004-09-06 20:23) [193]

Суслик ©   (06.09.04 20:18) [188]
Ты попробуй помучать дома штатный манагер:


Я сейчас дома ;-). Я отметил твой комментарий, просто сейчас лень :-) , но как нибудь поэксперементирую.


 
Суслик ©   (2004-09-06 20:24) [194]


> Меня больше необходимость этого для других типов интересует.

например ответить на вопрос на интервью при приеме на работу :))
видел такие вопросы.


 
Ермак ©   (2004-09-06 20:24) [195]

я же вроде говорил про виртуальную память?
Ты имеешь в виду другие страницы? Это что?

Я про то же самое. Не боись. Со времен ВИн95 у Микрософта фантазия иссякла. Нет бы еще какую нибудь супер-витруальную забабахать! "На вашем компьютере нет оперативной памяти. Включаем программную эмуляцию!"


 
Суслик ©   (2004-09-06 20:26) [196]


> jack128 ©   (06.09.04 20:23) [193]
> Я сейчас дома ;-). Я отметил твой комментарий, просто сейчас
> лень :-) , но как нибудь поэксперементирую.


уверен, тебя впечатлит штатный манагер. Но также впечатлит, тот факт, что в случае потребности некторые задачи можно ускорить очень сильно. И что самое главное задачи не будут зависеть от контекста (я имею в виду тот факт, что стоки, массивы, объекты также используют штатный манагер).


 
Nous Mellon ©   (2004-09-06 21:24) [197]

Удалено модератором


 
Игорь Шевченко ©   (2004-09-06 21:36) [198]

GrayFace ©   (06.09.04 19:44) [162]


> > Да и без макроподстановок в Дельфи как без рук.
> Эт еще нафига ?
> Для return, например. Без него тяжко.


Переведи пожалуйста свою глубокую мысль на понятный язык, можно на С++, можно на Delphi (это такой намек на пример в студию...)


> Не все программисты идеальны. Не все ХОРОШИЕ программисты
> идеальны - и у них бывают ошибки в проектировке.


Некоторые программисты отличаются еще чтением документации и изучением опыта других программистов. Оно рулез и источник знаний.


> Что именно ужасного в указателях в паскале ?
> К ним ничего нельзя прибавить. Единственный способ - inc,
> но в выражениях он не работает.


Ты будешь удивлен, но я опять попрошу проиллюстрировать глубокую мысль примером...


> Интерфейсов по-нормальному зделана в Java - там это вообще
> не сущьность, а как-бы класс объекта, но без методов. COM-интерфейсы
> для таких нужд мало пригодны, а множественное наследование
> - очень даже.


Опять же, поясни.

GrayFace ©   (06.09.04 19:49) [165]


> ИМХО, множественное наследование - это круто. Зря его заменили
> интерфейсы. Но все мои слова о C++ - это очень ИМХО... я
> на нем не програмировал, но от отца наслышан.


Я снимаю свои предыдущие просьбы. Для того, чтобы принимать участие в дискуссии, предмет дискуссии необходимо знать.
В ШКОЛУ!

Суслик ©   (06.09.04 20:03) [176]


> на счет времени жизни интерфейсов..


возьми объект, реализующий 2 интерфейса.


> Я что-то переключился на бучевствое определение интерфейса.
> Бывает...


В студию определение.

GrayFace ©   (06.09.04 20:04) [178]

> Я люблю работать с указателями, тем более, это очень сильно
> увеличивает скорость.


Чтобы перестать говорить чушь, открой окно CPU и посмотри генерируемый код.


 
Marser ©   (2004-09-06 21:45) [199]

Удалено модератором
Примечание: Offtopic


 
Sergey Kaminski ©   (2004-09-06 21:46) [200]


В коде, который должен быстро работать с тесктом, только ламер будет работать со стрингами


Я не стал бы заходить так далеко и называть брата "толстым" (с)


 
DiamondShark ©   (2004-09-06 23:10) [201]

Кстати, на счёт того, как нэймспейсы "решают" проблему конфликта имён.

//1.hpp
namespace Test {
 int A;
 int B;
}

//2.hpp
namespace Test {
 int A;
 int C;
}

//main.cpp
#include "1.hpp"
#include "2.hpp"


 
Игорь Шевченко ©   (2004-09-06 23:17) [202]

DiamondShark ©   (06.09.04 23:10) [201]

" error C2086: "A" : redefinition"


 
DiamondShark ©   (2004-09-06 23:30) [203]

Да, именно error.
Получается, что я могу вмешаться в процесс компиляции стороннего кода. Причём не препроцессором, который является, по сути, внеязыковым средством и за которым такая "дурная привычка" известна давно.


 
kull   (2004-09-07 00:04) [204]

Delphi то написан на Delphi, а вот компилятор то, dcc32 например, на C++, однако.


 
wicked ©   (2004-09-07 00:17) [205]

> DiamondShark ©   (06.09.04 23:10) [201]

> Кстати, на счёт того, как нэймспейсы "решают" проблему конфликта
> имён.

это еще понятно - редекларация переменной...
а вот чего действительно бы хотелось, так это модулей в стиле Pascal... а нэту... :(
например:
//Unit1.h
namespace Unit1 { // симитируем Pascal"евский модуль
   class MyClass{};
}
using namespace Unit1; // для полноты имитации Pascal

//Unit2.h
namespace Unit2 {
   class MyClass{}; // совсем другой класс, но назван так же
}
using namespace Unit2;

//main.cpp
#include "Unit1.h"
#include "Unit2.h"

void func
{
   MyClass x; // <-- Error: ambiguity between Unit1::MyClass
              // and Unit2::MyClass
}


а в паскале такие ситуации разруливаются на ура самим компилятором...


 
Sergey Kaminski ©   (2004-09-07 00:31) [206]


Delphi то написан на Delphi, а вот компилятор то, dcc32 например, на C++, однако.


А каждая новая версия gcc.exe написана на предыдущей версии gcc.exe, однако. Из этого "следует", что каждая последующая версия gcc -- отстой, на ней нельзя написать нормальный компилятор, а предыдущая "рулит"
%-\


 
pasha_golub ©   (2004-09-07 00:33) [207]

Удалено модератором


 
Marser ©   (2004-09-07 00:42) [208]

Удалено модератором


 
DiamondShark ©   (2004-09-07 00:45) [209]


> pasha_golub ©   (07.09.04 00:33) [207]

Очень содержательно, а главное -- в тему.
А тебе-то чего неймётся?


 
pasha_golub ©   (2004-09-07 00:48) [210]

Удалено модератором


 
Marser ©   (2004-09-07 00:48) [211]

Удалено модератором


 
pasha_golub ©   (2004-09-07 00:50) [212]

DiamondShark ©   (07.09.04 00:45) [209]
Дык, на работе дверь захлопнулась, а тут гляжу ты в главных ролях, а потом гляжу уже и Суслик - быдло. Ну, думаю, надо посмотреть.

Зы Еще раз с прошедшим тебя. :0)


 
pasha_golub ©   (2004-09-07 00:52) [213]

Удалено модератором


 
Marser ©   (2004-09-07 00:54) [214]

Удалено модератором


 
pasha_golub ©   (2004-09-07 00:55) [215]

DiamondShark ©   (07.09.04 00:45) [209]
Кстати, в тему...

М-м-м, Дима прав однако. Ц++ мастдай. Неймспайсы - костыли. Руки должны быть прямые.


 
jack128 ©   (2004-09-07 01:15) [216]

pasha_golub ©   (07.09.04 0:55) [215]
Вот вот. Прямыми должны быть руки, а не извилины :-))


 
kull   (2004-09-07 02:08) [217]


> Sergey Kaminski ©


> А каждая новая версия gcc.exe написана на предыдущей версии
> gcc.exe, однако. Из этого "следует", что каждая последующая
> версия gcc -- отстой, на ней нельзя написать нормальный
> компилятор, а предыдущая "рулит"
> %-\

Не следует... Я как раз и неговорил не о каком отстое. Просто наиважнейшая хоть и не большая (нравится тут многим мегабайтные exe-шники в пример ставить) часть пакета написаниа на C++, кстати та часть и именно тот компилятор, скорость которого так хвалят.

Просто факты излагаем-с. А то многие флаг впереди несут, мол Delphi на Delphi написана.

Кстати Borland в последнее время Delphi не очень то жалует...


 
Sergey Kaminski ©   (2004-09-07 03:22) [218]

kull   (07.09.04 02:08) [217]

Я так понимаю, вам бы хотелось, чтобы компилятор Делфи был написан на Делфи :) кхм...


 
SkyRanger ©   (2004-09-07 06:31) [219]

Такой вопросец:
А Borland C Builder последних версий енто у нас тожа C++ ???
Почитал интерьвью с создателем, если это правда то чувак нехило прикололся...


 
Думкин ©   (2004-09-07 07:05) [220]

> [140] GrayFace ©   (06.09.04 18:37)
> А что такое Cabol? На Basic - это да. Только треть программ на Basic"е - это рисоваание машинки и т.п(возможно даже едущей), другая треть - вычисление факториала и т.п., а третья - это проги для Емахи и т.д.

Уровень проявленной грамотности в сочетании с прочтением Вашего кода для калькулятора - делает вас весьма достойным оппонетом.
Не Cabol, а Cobol.

Советую прочитать книгу
С. Бобровский
Программная инженерия. Технологии Пентагона на службе российских программистов

Хотя бы Глава 2 •Языки программирования: прошлое и будущее

А потом не постить стользабавный материал для орешника в столь значительных объемах.


 
Dok_3D ©   (2004-09-07 07:50) [221]

Спасибо, Думкин, что обратил мое внимание на пост GrayFace"а :))
Ну парень выдал перлы :))).
Причем сразу в таких количествах и таком назидательном тоне, я минут пять смеялся.:)


 
DiamondShark ©   (2004-09-07 08:26) [222]


> Кстати Borland в последнее время Delphi не очень то жалует...

Целых восемь версий всё не жалует, да не жалует...


 
Григорьев Антон ©   (2004-09-07 09:44) [223]


> Ермак ©   (06.09.04 19:09) [147]
> Вполне согласен. А вот про Оберон можно чуть подробнее?
> Що це такэ и с чем его ядят?


Вот здесь все ссылки: http://www.delphikingdom.com/asp/talktopic.asp?ID=285


 
pasha_golub ©   (2004-09-07 10:01) [224]

Думкин ©   (07.09.04 07:05) [220]
Сурово ты, однако. Сурово.


 
Думкин ©   (2004-09-07 10:14) [225]

> [224] pasha_golub ©   (07.09.04 10:01)

Бывает. Но ... бывает.


 
kull   (2004-09-07 10:18) [226]


> Sergey Kaminski ©   (07.09.04 03:22) [218]

Нет, мне, если честно, все равно на чем он написан. ;)
Однако ПОЧЕМУ?


 
Amoeba ©   (2004-09-07 12:17) [227]


> kull   (07.09.04 00:04) [204]
> Delphi то написан на Delphi, а вот компилятор то, dcc32
> например, на C++, однако.

Компилятор D1 был написан на BP7. А вот компилятор D2 пришлось писать на Borland C в первую очередь (IMHO) бы из за того, что 32-х разрядного компилятора Pasсal на тот момент просто не существовало. А вот почему эта традиция продолжилась, не очень ясно.


 
Акуличев Дмитрий   (2004-09-07 12:23) [228]


> А вот почему эта традиция продолжилась, не очень ясно.

А исходники жалко было выбрасывать ;)


 
Суслик ©   (2004-09-07 12:31) [229]


> Игорь Шевченко ©   (06.09.04 21:36) [198]
> Суслик ©   (06.09.04 20:03) [176]
>
>
> > на счет времени жизни интерфейсов..
>
>
> возьми объект, реализующий 2 интерфейса.
>
>
> > Я что-то переключился на бучевствое определение интерфейса.
>
> > Бывает...
>
>
> В студию определение.

Тебе прада нужно определиние - у тебя же все эти книги есть, сам посмотри. К интерфейсу в дельфи это имеет нетождественное отношение.

По поводу времени жизни.

>>возьми объект, реализующий 2 интерфейса.

И что ты мне этим хочешь сказать?. Что интерфейс в дельфи может жить меньше, чем объект, так это очевидно. Суть моего утверждения, что то, что за меня дельфи вообще реализует жизнь интерфейса и не есть хорошо (для меня). Я вполне был бы рад следить за жизнью интрефейса сам.


 
Игорь Шевченко ©   (2004-09-07 12:38) [230]

Суслик ©   (07.09.04 12:31) [229]

Я присоединяюсь к Диме Акуличеву и дальнейшую дискуссию считаю бесполезной. Учи матчасть.


 
karat ©   (2004-09-07 12:40) [231]

К вопросу о различном написанном софте на Delphi.
Судя по присланному мне коду некоторых функций проверок, программисты из Российского Союза Автостраховщиков используют Delphi.
Объемы данных, которые они обрабатывают достигает милионны записей. И все у них работает.


 
Sergey_Masloff   (2004-09-07 13:26) [232]

karat ©   (07.09.04 12:40) [231]
Ну мне они зачем-то присылали код расчета CRC32 на C (который никто не просил и который я сам 100 раз писал и на С и на Pas и на ASM еще бы и их поучить мог). Это значит что они на С пишут? ;-)

 Вообще у меня о ИТ в РСА мнение несколько... ну ладно не будем о грустном.


 
Sergey_Masloff   (2004-09-07 13:30) [233]

И вообще это тут не при чем.

Я с какого-то времени спорить на эти темы перестал. Обычно говорю да, С (С++, С#, VB - подставь по умолчанию) конечно намного круче. И на этом разговор заканчиваю. Мне от этого не жарко не холодно.


 
Суслик ©   (2004-09-07 13:30) [234]


> Игорь Шевченко ©   (07.09.04 12:38) [230]

да мне в общем-то все равно к кому ты присоединяешься и считаешь ли ты дискуссию бесполезной - это твое дело.
если ты что-то найдешь по интерфейсам (ключевое слово interface), то что я не знаю, очень рад буду услышать:
1) учи матчасть
2) ламери дома
3) и пр.

Не найдешь же ведь только :(


 
Ihor Osov'yak ©   (2004-09-07 13:52) [235]

2 Суслик ©   (07.09.04 13:30) [234]

> 2) ламери дома

И это по отношению к И. Шевченко?  Давно я так не ржал...


 
pasha_golub ©   (2004-09-07 13:59) [236]

Ihor Osov"yak ©   (07.09.04 13:52) [235]
Это не пожелание Игорю, а наоборот разрешение...


 
Sergey_Masloff   (2004-09-07 14:00) [237]

Ihor Osov"yak ©   (07.09.04 13:52) [235]
Ты похоже пост Суслика неправильно понял. Он вроде имеет ввиду что и рад бы если б его обозвали если есть что-то чего он не знает и из-за этого обходными путями действует. Только сомневается что такое возможно.

Я прям как толкователь.


 
Суслик ©   (2004-09-07 14:01) [238]


> Ihor Osov"yak ©   (07.09.04 13:52) [235]

А внимательней читать? Нет? :)))

-------------
Да в общем-то неважно - я начинаю понимать, что проблема форума в недопонимании друг друга вследитвии невнимательного чтения :(((
-------------
Ах, да! Еще проблемы в горячности отедельных индивидумов в вносе вердикта - ламер/НЕламер :)))


 
Суслик ©   (2004-09-07 14:01) [239]


> Sergey_Masloff   (07.09.04 14:00) [237]

Тут похоже все все неправильно понимают.
Не первый раз.


 
Vovchik_A ©   (2004-09-07 14:05) [240]

2Суслик ©   (07.09.04 14:01) [238]
Ну да, все правильно... Все остальные лохи, один ты святее папы римского


 
Суслик ©   (2004-09-07 14:08) [241]


> Vovchik_A ©   (07.09.04 14:05) [240]


> Все остальные лохи, один ты святее папы римского

ну ты и фантазер :))


 
Ihor Osov'yak ©   (2004-09-07 14:17) [242]

2 Суслик ©  

С привода  [235]  - сори..

Но вот -
> если ты что-то найдешь по интерфейсам (ключевое слово interface), то что я не знаю, очень рад буду услышать:

см. [95]
>Такое часто возникает при подмесе модели интерфесов с моделью объектов. Почти все авторы, кто упоминает интерфейсы в дельфи не рекоммендуют так делать. Но все же приходится.

Можно долго обьяснять, почему это плохо. Но есть подозрение, что человеку это говорилось не единыжды. И в книгах, наверное, рассуждение на эту тему виделось  не раз. Но почему-то было проигнорировано. Мало того, лично я придерживаюсь мнения, что если немного включить соображаловку, то можно и самому сообразить (без чтения соотв. выводов в книжках), почему так делать плохо. Поэтому - извините за грубость - LMD.

Зы. Знания, они не для того, чтобы на полку складывать. Или поступать вопреки знаниям. Их на деле применять нужно.


 
Romkin ©   (2004-09-07 14:19) [243]

Суслик ©   (07.09.04 14:01) [239] Правильно изложенные утверждения поймут все.

А вот такое:
---
Суслик ©   (06.09.04 15:29) [95]
> Игорь Шевченко ©   (06.09.04 15:24) [92]
> Чего именно тебе не хватает, что "не то" ?

Конкретный?

Иногда надо, иногда не надо вызывать _release?

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

Убить вызов релиза просто:

i: ISome;

i := nil; // не так писать, а
pointer(i) := nil; // вот так.

Но это же разврат :(((

---
Romkin ©   (06.09.04 15:33) [97]
Суслик ©  (06.09.04 15:29) [95] Ничуть не разврат :)) А не проще дополнительно сделать вызов addref? ;)

---
Суслик ©   (06.09.04 15:35) [98]
> Romkin ©   (06.09.04 15:33) [97]

конечно можно.
Но я бы больше был рад отмене на уровне компиляции соответсвующих вызовов (например директивами). ПО моему мнению, сложившемуся на основе анализа cpu, это было бы сделать несложно.

---
Romkin ©   (06.09.04 15:48) [102]
Суслик ©  (06.09.04 15:35) [98] Тебе подсчет ссылок совсем отключитиь надо? Так не наследуйся от TInterfacedObject :)
Обрати внимание на TVCLCOMObject...
И, наконец, что мешает прямо где нать объявить свои
function _AddRef: Integer; stdcall;
function _Release: Integer; stdcall;
А? Они подцепятся ;)

---
Суслик ©   (06.09.04 15:49) [104]
> Romkin ©   (06.09.04 15:48) [102]
как же тут все невнимательно читают посты других :)))

??? !

Внимательно я читаю. И дал несколько способов, как отключить потсчет ссылок в ответ на [98] - Отключение на уровне компиляции. И "отключение иногда" тоже можно реализовать так. А вот некоторым, которые кричат, что их не понимают, надо бы выражать свои мысли яснее ;))
Не все настолько умные...


 
Romkin ©   (2004-09-07 14:25) [244]

А насчет Суслик ©   (07.09.04 13:30) [234]
1. перечисли, плиз, способы внутрипроцессного маршалинга интерфейсов? Кратенько...
2. Что такое специальный маршалинг и как делается?


 
Суслик ©   (2004-09-07 14:27) [245]


> Ihor Osov"yak ©   (07.09.04 14:17) [242]


Рад плодотворной дискуссии:))

> Можно долго обьяснять, почему это плохо. Но есть подозрение,
> что человеку это говорилось не единыжды.

Зачем говорить - я и так знаю, что это в рамках Дельфи плохо.

Проблема, исключительно в 1000 человеко часах, которых нет, чтобы перевести миллионстрочный проект на новые рельсы. Потому и приходится. Если бы было управление временем жизни интерфейса, то и проблем бы не было.

Вот скажи мне - как ты считаешь, почему плохо мешать модель инт. и об.? Конечно, тем, что при приведении вызывается _addref а потом _release? Ну согласись, что если бы я имел возможность этим процессом управлять - ты вряд ли бы нашел другие подтверждения недопустим подмеса моделей. Или нашел бы? Тогда в слуди (если не затруднит).

ЗЫ. Про ЛМД я запомню :)))


> Romkin ©   (07.09.04 14:19) [243]


> Не все настолько умные...

Да ладно, брось - все хорошо :)))

Ты думаешь я хоть один из этих способов не знаю? Зря.
Ты посмотри на тему - холи вор. По ходу рассуждения я сказал, что если бы бы процесс управления на уровне компилятора (без изврата типа ponter(i) := nil) я был бы рад. Все! Более я ничего сказать не хотел. Если уж сказал, то извините - вор все-таки. :)))


 
Суслик ©   (2004-09-07 14:29) [246]


> Romkin ©   (07.09.04 14:25) [244]

Роман - это к интерфейсам не относится :)))
Интерфейсы это независимая и плодотворная идея ((с) Акуличев), которая и без маршалинга живет.

В данном случае ты спрашиваешь про использование этой независимой и плодотворной идеи, реализованной в компиляторе.

Ну?


 
Romkin ©   (2004-09-07 14:33) [247]

Суслик ©   (07.09.04 14:29) [246] Чего-чего? CoMarshalInterface - это реализовано в компиляторе? Ну, в принципе, конечно, через компилятор она прошла...

Хорошо, вопросы попроще:
1. Какими свойствами по соглашениям СОМ должна обладать реализация QueryInterface?
2. Какими способами и для чего можно и нужно использовать IStream?


 
Суслик ©   (2004-09-07 14:34) [248]


> Romkin ©   (07.09.04 14:33) [247]

Роман, одумайся ты про com спрашиваешь!
Я тебе при личной встрече говорил, что ком не знаю! Вообще, писал парочку комов, но это так про книгам.


 
vuk ©   (2004-09-07 14:36) [249]

to Суслик ©   (07.09.04 14:27) [245]:
>если бы я имел возможность этим процессом управлять
Как же себе представляется такое управление? Только поподробнее плиз, а не в стиле "хочу, чтоб былО".


 
Romkin ©   (2004-09-07 14:40) [250]

Суслик ©   (07.09.04 14:34) [248] Да это я по поводу:

Суслик ©   (07.09.04 13:30) [234]
> Игорь Шевченко ©   (07.09.04 12:38) [230]
>да мне в общем-то все равно к кому ты присоединяешься и считаешь ли ты дискуссию бесполезной - это твое дело.
>если ты что-то найдешь по интерфейсам (ключевое слово interface), то что я не знаю, очень рад буду услышать:
>1) учи матчасть
>2) ламери дома
>3) и пр.

>Не найдешь же ведь только :(

Любой интерфейс содержит QueryInterface :)))
Какими свойствами по соглашениям СОМ должна обладать реализация QueryInterface?
В принципе, эти соглашения действуют не только в СОМ ;)
И если ты работаешь с интерфейсами, ЭТО ты обязан знать...

PS. Игорь Шевченко знает :)


 
Суслик ©   (2004-09-07 14:42) [251]


> Romkin ©   (07.09.04 14:40) [250]


> В принципе, эти соглашения действуют не только в СОМ ;)
> И если ты работаешь с интерфейсами, ЭТО ты обязан знать...

Я это знаю :)))
Ты вспомни вопрос -

> 1. Какими свойствами по соглашениям СОМ должна обладать
> реализация QueryInterface?

это разве не про ком?

Извини перевести не успел :)))

Returns a reference to a specified interface if the object supports that interface.

type HResult = Longint;
function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;

Description

QueryInterface checks whether the object that implements this interface supports the interface specified by IID. If so, QueryInterface

increments the reference count.
sets the Obj parameter so that it points to an instance of the specified interface.
returns 0 to indicate success.

If the object does not support the interface, QueryInterface returns a nonzero error code such as E_NoInterface.


 
Суслик ©   (2004-09-07 14:45) [252]


> vuk ©   (07.09.04 14:36) [249]

Например так

type
  TObj = class(TInterfacedObject, IInterface)
  end;
{$IntfRefConting OFF}
procedure TForm1.Button1Click(Sender: TObject);
var
  O: TObj;
  I: IInterface;
begin
  O := TObj.Create;
  I := O;
end;
{$IntfRefConting ON}

В этом случае в конце процедуры в коде не будет
0045235A E8ED3BFBFF       call @IntfClear

Я предполагаю, что могут быть сложности в информацией о record, и как следствие с initialize и finlize. Но это легко рарширяемо детализацией информации о типе.


 
Суслик ©   (2004-09-07 14:47) [253]


> Суслик ©   (07.09.04 14:45) [252]

Дополение

и соответственно
0045233B E8243CFBFF       call @IntfCopy
будет работать по другому - без _addref.


 
Акуличев Дмитрий   (2004-09-07 14:48) [254]


> Суслик ©   (07.09.04 14:42) [251]

Двойка.


 
Суслик ©   (2004-09-07 14:49) [255]


> Акуличев Дмитрий   (07.09.04 14:48) [254]

да ну


 
Romkin ©   (2004-09-07 14:49) [256]

Суслик ©   (07.09.04 14:42) [251] Увы, увы. Эт не то. Я спрашивал о свойствах, а не о назначении :))
К сожалению, именно о задекларированных свойствах мало кто знает :( (Особенно из дельфистов, за них ужо в Борланде это сделали...)
Дело в том, что когда ты используешь слово interface в Delphi, ты работаешь так или иначе с СОМ. И здесь надо понимать, что и как там происходит, что ты можешь делать, и чего - нет.
Дело в том, что реализация интерфейсов в Delphi и иерархия VCL для их поддержки - одна из лучших, если не самая лучшая. Бедным сишникам приходится постоянно ставить addref & release, и не дай бог что-то потеряется :))) А ты ноешь, что в Delphi это сделано автоматом?!


 
Суслик ©   (2004-09-07 14:51) [257]


> Акуличев Дмитрий   (07.09.04 14:48) [254]


> Romkin ©   (07.09.04 14:40) [250]

Хорошо.
Обращаюсь к вам, господа знающие, объяснить, что я в рамках НЕ СOM технологии должен знать про queryinterface, что я не знаю, т.е. в чем я был не прав, когда привел выдержку из справки?

Буду очень благодарен.


 
Суслик ©   (2004-09-07 14:54) [258]


> А ты ноешь, что в Delphi это сделано автоматом?!


> К сожалению, именно о задекларированных свойствах мало кто
> знает :( (Особенно из дельфистов, за них ужо в Борланде
> это сделали...)

Очень рад - значит я в незнающем большинстве. Изучение матчасти не поможет.

А ты ноешь, что в Delphi это сделано автоматом?!

Не ною, а говорю, что это право компилятор мог бы и иначе код строить.

ЗЫ. Про слова о том, что инт-сы неясно всегда ком, я не знал. Каюсь. Где ты это читал - ни в справке, ни в хармоне я этого не видел?


 
vuk ©   (2004-09-07 14:56) [259]

to Суслик ©   (07.09.04 14:45) [252]:
>В этом случае в конце процедуры в коде не будет
Пример элементарный и, скорее всего, в реальности будет:


procedure TSomeClass.SomeMethod(Param: ISomeInterface);
begin
...  
end;


Или при смешении моделей


procedure TSomeClass.SomeOtherMethod(Param: TSomeObject);
var
 intf: ISomeInterface;
begin
 if Param.GetInterface(ISomeInterface, intf) then
  ...
end;


Здесь что делать? Считать или нет? :o)


 
vuk ©   (2004-09-07 14:57) [260]

to Romkin ©   (07.09.04 14:49) [256]:
>Дело в том, что когда ты используешь слово interface в Delphi,
>ты работаешь так или иначе с СОМ.
Не согласен. Спорить бум? :o)


 
Суслик ©   (2004-09-07 14:57) [261]


> vuk ©   (07.09.04 14:56) [259]


> Здесь что делать? Считать или нет? :o)

думаю зависит от мифических обсуждаемых директив.
Я согласен - трудностей много будет.


 
Суслик ©   (2004-09-07 14:58) [262]


> vuk ©   (07.09.04 14:57) [260]

Лахааааа!!!! Поддержим меня - я тоже это первый раз слышу!
К тому же я смотрел cpu - я не видел никогда ничего похожее на ком...


 
Romkin ©   (2004-09-07 14:59) [263]

Суслик ©   (07.09.04 14:51) [257] ОК. По действующим соглашениям,  реализация QueryInterface должна обладать следующими свойствами:
1. Симетричность
2. Транзитивность
3. Рефлексивность
1. Симметричность: Если из интерфейса А вы успешно получили интерфейс В, то, запрос интерфейса А из В также обязан быть успешным
2. Транзитивность: Если был успешный запрос В у А, и также был успешен запрос интерфейса С у В, то запрос С у А также должен быть успешным. if QI(QI(A)->B)->C then QI(A) -> C
3. Рефлексия: QI(A)->A, т.е. запрос из интерфейса его же всегда успешен.
СОМ предусматривает усиление данного свойства: запрос IUnknown всегда возвращает одно и то же значение. Поэтому на вопрос "Реализуются ли все эти интерфейсы одним классом?" очень легко ответить :))


 
Суслик ©   (2004-09-07 15:02) [264]


> Romkin ©   (07.09.04 14:59) [263]

Спасибо, полезно будет знать - может где нить блестнуть знаниями прийдется :)))


 
Суслик ©   (2004-09-07 15:04) [265]


> Romkin ©   (07.09.04 14:59) [263]

Интересно где ты эти правила взял. Полагаю, что все-таки из книг по COM? Правила все логичные, но я их ни в одной книге по интерфейсам в дельфи ни в доке не видел.

Так откуда ты их взял?


 
vuk ©   (2004-09-07 15:04) [266]

to Суслик ©   (07.09.04 14:57) [261]:
>думаю зависит от мифических обсуждаемых директив.
>Я согласен - трудностей много будет.
Я не зря говорил, что хочу подробное описание, а не "хочу, чтобы былО". О трудностях надо думать заранее, до того, как громко говорить "хочу".

to Суслик ©   (07.09.04 14:58) [262]:
>Поддержим меня - я тоже это первый раз слышу!
Ну... Я уже не в первый. :o) Но тут есть одна тонкость - правила работы с интерфейсами в Delphi соответствуют правилам работы с интерфейсами в COM. Поэтому знать их не мешает. Но вот говорить, что используя интерфейсы, используешь COM - в корне не верно.


 
Ihor Osov'yak ©   (2004-09-07 15:04) [267]

2 Суслик ©
В принцыпе, по существу и коротко - см. [249].

Если более пространно - я подозреваю, что вы ухватились только за одну "фишку" интерфейсной ссылки (aka interface) - способность скрывать часть програмного интерфейса (ака набор методов) обьекта, который хостит (реализовывает) соответсвующий интерфайс. Понятие интерфейса немного шире.
Еще. Это понятие появилось как часть технологии COM. И даже если интерфейсы поддерживаются на уровне синтаксиса делфи, и даже если интерфейсы в делфи можно использовать не только в контексте СOM - то это не значит, что нужно нарушать соглашения относительно интерфейсов и обьектов их хостящих. Хотя бы потому, что ваш код будет совершенно непонетен другому человеку. Немного преувеличив, можно сказать, что ваше желание относительно времени жизни интерфейсов примерно то, когда  в с++  оператор + переопределить так, что вместо сложения он будет делать вычетание для целочисельных. Можно, конечно. Но ни один здравормыслящий не будет делать этого.
Здесь бы хотел-бы напомнить слова, услышанные на этом форуме. Авторства, к соджалению, не помню. Суть такова: "Ребята, давайте помнить, что мы программируем под платформу Microcoft Windows. Поэтому давайте будем соблюдать рекомендации Microcoft по программированию под эту платформу".

Далее. Относительно смешивания обьектных и интерфейсных ссылок. Дело в том, что эти две модели подразумевают противоречивые модели управления временем жызни обьектов. И по-человечески эти противоречия не разрешить. Конечно, можно искать приключения на одно место. Но это уже из розряда LMD. Я понимаю, могут быть исключения в мелком проекте, в отдельном случае. Подробно комментированном. Но в большом - сорри. Даже как временная, и переходная мера. Здесь я напомню слова одной моей школьной учительницы: "Сначала думай, а тогда делай". Она их очень часто повторяла. Это раздражало. Но теперь есть понимание, что она правильно делала. И это, в общем, пошло на пользу.

> ЗЫ. Про ЛМД я запомню :)))

Да ладно, мне не жалко. Тем более, здесь не случай дыма без огня.


 
Суслик ©   (2004-09-07 15:07) [268]


> vuk ©   (07.09.04 15:04) [266]


> Я не зря говорил, что хочу подробное описание, а не "хочу,
> чтобы былО". О трудностях надо думать заранее, до того,
> как громко говорить "хочу".

Алексей. Они (трудности) - разрешимы. Я привел одну из самых больших доделок, которые пришлось бы делать Борланду - дополнение информации о типах - иначе не будет корректно работать подчистка мусора из записей, классов и пр.


> о тут есть одна тонкость - правила работы с интерфейсами
> в Delphi соответствуют правилам работы с интерфейсами в
> COM

Радостно - значит я не потерян для COM - что-то знаю :))


 
Ihor Osov'yak ©   (2004-09-07 15:08) [269]

Microsoft конешно, сори.


 
vuk ©   (2004-09-07 15:08) [270]

to Суслик © (07.09.04 15:07) [268]:
>Они (трудности) - разрешимы.
Пути разрешения - в студию.


 
Акуличев Дмитрий   (2004-09-07 15:09) [271]


> Суслик ©   (07.09.04 14:51) [257]

Четыре свойства интерфейсов:

Устойчивость.
Набор реализуемых интерфейсов не должен меняться за время жизни объекта.

Рефлексивность.
Если A: IA, то A.QueryInterface(IA, x) = S_OK

Симметричность.
Если A: IA, B: IB, A.QueryInterface(IB, B) = S_OK, то B.QueryInterface(IA, x) = S_OK

Транзитивность.
Если A: IA, B: IB, C: IC, A.QueryInterface(IB, B) = S_OK, B.QueryInterface(IC, C) = S_OK, то A.QueryInterface(IC, C) = S_OK


 
Суслик ©   (2004-09-07 15:11) [272]


> Ihor Osov"yak ©   (07.09.04 15:04) [267]

Спасибо за объяснения про то, что нужно соблюдать соглашения. Хорошо все объяснил.


> Но в большом - сорри. Даже как временная, и переходная мера.

Над тем и работаем, чтобы изничтожить - работы много.


 
Romkin ©   (2004-09-07 15:13) [273]

vuk ©   (07.09.04 14:57) [260] Дfвай :)) Возможно, я не точно выразился, каюсь.


program Project1;

{$APPTYPE CONSOLE}

type
 IMyIntf = interface
   procedure Show(msg: string); stdcall;
 end;

 TMyIntf = class(TInterfacedObject, IMyIntf)
   procedure Show(msg: string); stdcall;
 end;

var
 MyIntf: IMyIntf;

{ TMyIntf }

procedure TMyIntf.Show(msg: string);
begin
 writeln("AAA");
end;

begin
 MyIntf := TMyIntf.Create;
 MyIntf.Show("");
 readln;
end.


Посмотри список загруженных модулей ;)
PS Delphi 6


 
vuk ©   (2004-09-07 15:14) [274]

to Акуличев Дмитрий   (07.09.04 15:09) [271]:
>Набор реализуемых интерфейсов не должен меняться за время жизни
>объекта.
Кстати, как в этом отношении с агрегируемыми объектами быть, если устроить такую ситуацию, когда контейнер может предоставлять клиентам интерфейсы агрегируемых объектов как свои?
:o)


 
Суслик ©   (2004-09-07 15:14) [275]


> vuk ©   (07.09.04 15:08) [270]

Давай сначала проблемы? Ты пока ни одной не привел...


> Акуличев Дмитрий   (07.09.04 15:09) [271]


Спасибо.
Все же есть ощущение, что это из COM?
Я конечно внимательно прочел 267, про то, что интерфейсы вышли из ком? Но почему тогда нигде, где бы говорилось про интерфейсы в дельфи нет этих правил?.


 
Акуличев Дмитрий   (2004-09-07 15:16) [276]


> Суслик ©   (07.09.04 15:04) [265]
> Интересно где ты эти правила взял. Полагаю, что все-таки
> из книг по COM? Правила все логичные, но я их ни в одной
> книге по интерфейсам в дельфи ни в доке не видел.
>
> Так откуда ты их взял?

Интерфейсы появились отнюдь не в COM.
Впрочем, что взять с человека, который слова "много читаешь" использует как упрёк...


 
Romkin ©   (2004-09-07 15:19) [277]

Суслик ©   (07.09.04 15:04) [265] Это фактически цитата из "Сущность технологии СОМ" Дональда Бокса. Примерно то же самое можно найти и у др. Джейсона Причарда "СОМ и CORBA"


 
Суслик ©   (2004-09-07 15:19) [278]


> Впрочем, что взять с человека, который слова "много читаешь"
> использует как упрёк...

Забей. Это не упрек. Дело в том, что начитанные люди не слушают друих и считают себя в праве давать оценки. Забей.

------------
Все же есть ощущение, что данные правила есть требования контекста. В данном случае COM. Если бы они были важны для реализации интерфейсов в дельфи как таковых, то об этом обязательно было бы сказано в соответсвующей литературе.


 
Суслик ©   (2004-09-07 15:19) [279]


> Romkin ©   (07.09.04 15:19) [277]


> Это фактически цитата из "Сущность технологии СОМ" Дональда
> Бокса. Примерно то же самое можно найти и у др. Джейсона
> Причарда "СОМ и CORBA"

Вот! Все-таки COM...


 
vuk ©   (2004-09-07 15:21) [280]

to Romkin ©   (07.09.04 15:13) [273]:
>Посмотри список загруженных модулей
А разобраться, зачем это нужно, в RTL посмотреть? :o)


 
vuk ©   (2004-09-07 15:25) [281]

to Суслик ©   (07.09.04 15:14) [275]:
>Давай сначала проблемы? Ты пока ни одной не привел...
Два фрагмента кода я привел. Если сходу не видно проблемы с этим кодом при наличии гипотетической директивы то я уже и не знаю...


 
Romkin ©   (2004-09-07 15:25) [282]

Суслик ©   (07.09.04 15:19) [279] и CORBA, заметь. :))


 
Акуличев Дмитрий   (2004-09-07 15:25) [283]


> vuk ©   (07.09.04 15:14) [274]

Ну как... Очень просто. Так как единственный способ узнать набор реализуемых интерфейсов -- запросить какие-либо, то ДО момента запроса какого-либо интерфейса объект может с агрегантами творить что угодно.

Вообще-то, этот постулат не независимый. Он следует из других.
Можно переформулировать этот постулат так:

Если x.QueryInterface(Ix, y) = S_OK, то x.QueryInterface(Ix, y) = S_OK

Или, по-русски, однажды успешно запрошенный интерфейс всегда запрашивается успешно.


 
Romkin ©   (2004-09-07 15:27) [284]

vuk ©   (07.09.04 15:21) [280] А вот зачем это надо - я так и не понял :((


 
Суслик ©   (2004-09-07 15:27) [285]


> vuk ©   (07.09.04 15:25) [281]

согласен :)

БОРЛАНДУ
Предложение сделать управление временем жизни интерфейса снимается в виду отстутсвия требуемой суммы денег :)))


> Romkin ©   (07.09.04 15:25) [282]

Ты не увиливай :)))
Данноые требования есть следствия контекста механизма интерфейсов :))


 
Ihor Osov'yak ©   (2004-09-07 15:33) [286]

2 Romkin ©   (07.09.04 14:59) [263]

>Поэтому на вопрос "Реализуются ли все эти интерфейсы одним классом?" очень легко ответить :))

Ответ: А хр.. его знает, товарищ майор, чем они там реализуется..

Зы. Или я чего-то недопонимаю?


 
Romkin ©   (2004-09-07 15:35) [287]

>Данноые требования есть следствия контекста механизма интерфейсов :))

Чего сказал-то? Честно - я не понял :)) То, что я привел, это именно соглашения. Вполне действующие


 
Суслик ©   (2004-09-07 15:37) [288]


> Romkin ©   (07.09.04 15:35) [287]


> Чего сказал-то? Честно - я не понял :))

да ладно забей, я уже раз 5 говорил это :)

Я хочу сказать, что знать эти правила для владения интерфейсами не обязательно, т.к. они есть требования определенной технологии, базирующейся на интерфейсах.


 
Акуличев Дмитрий   (2004-09-07 15:38) [289]


> Суслик ©   (07.09.04 15:19) [278]
> Все же есть ощущение, что данные правила есть требования
> контекста. В данном случае COM. Если бы они были важны для
> реализации интерфейсов в дельфи как таковых, то об этом
> обязательно было бы сказано в соответсвующей литературе.

Это правила реализации интерфейсов вообще.


 
vuk ©   (2004-09-07 15:39) [290]

to Суслик ©   (07.09.04 15:37) [288]:
>Я хочу сказать, что знать эти правила для владения интерфейсами
>не обязательно
Угу, точно. Проще рассказывать о нехватке мифических директив. :o)


 
Romkin ©   (2004-09-07 15:40) [291]

Суслик ©   (07.09.04 15:37) [288] Неа :)) Это - именно соглашения!!! Нет в СОМ (да, кажется, и нигде) механизмов, которые били бы разработчика по башке за их несоблюдение. Вот в чем дело. Тебе никто и ничто не мешает написать QueryInterface, которая нарушит все эти соглашения. Работать будет ;) Но остальные разработчики будут плеваться...


 
Суслик ©   (2004-09-07 15:43) [292]


> Акуличев Дмитрий   (07.09.04 15:38) [289]


> vuk ©   (07.09.04 15:39) [290]


> Romkin ©   (07.09.04 15:40) [291]

Чтобы я вам троим поверил, найдите в документации по интерфейсам в дельфи и даже по COM в дельфи список этих требований.

Заранее благодарен.


> vuk ©   (07.09.04 15:39) [290]

Правила для QI имеют по ходу дискуссии отношение к директивам? Если скажешь да, ну тогда просто не знаю что сказать ...


 
Romkin ©   (2004-09-07 15:45) [293]

Ihor Osov"yak ©   (07.09.04 15:33) [286] :))) Да обычно и знать-то не надо. Но если понадобится - запроси IUnknown и сравни два указателя :))
Суслик ©   (07.09.04 15:37) [288] Кстати, у этих соглашений есть следствия, одно из них Дмитрий Акуличев привел: если первый запрос интерфейса был успешным, то остальные обязаны быть успешными. Это не должно зависеть ни от времени суток, ни от прав доступа, ни от наличия или отсутствия ресурсов...
И тд.


 
Суслик ©   (2004-09-07 15:47) [294]


> Romkin ©   (07.09.04 15:45) [293]

Ты мне про соглашения больше того, не надо... :))))

Ты меня хотел поймать, что я не знаю что-то про ключевое слово interface. Заметь я не говорил, что знаю com. Так вот - найди хоть в одной доке по дельфи эти соглашения и я пойду ламерить дома :)))) благо гости сегодня прийдут.


 
vuk ©   (2004-09-07 15:51) [295]

to Суслик [292]:
>Чтобы я вам троим поверил
Незнание, как известно, не освобождает. Не вериться - ну и ладно. :o)

>Правила для QI имеют по ходу дискуссии отношение к директивам?
Я про общий подход к делу. :o)


 
Суслик ©   (2004-09-07 15:53) [296]


> vuk ©   (07.09.04 15:51) [295]


> Я про общий подход к делу. :o)

Ну это уже ты обобщил - право твое.

Согласен - слово "вера" не очень подходит. Я вам верю. См. 294


 
vuk ©   (2004-09-07 15:54) [297]

to Суслик ©   (07.09.04 15:47) [294]:
>Так вот - найди хоть в одной доке по дельфи эти соглашения
Вообще говоря, некоторые намеки есть в теме про COM Aggregation. Но вообще для понимания, что это такое и зачем все это нужно, лучше читать что-нибудь типа книжки "Основы COM".


 
Суслик ©   (2004-09-07 15:55) [298]


> vuk ©   (07.09.04 15:51) [295]

И вообще, чем тебе подход не нравится. Соответствующая лит-ра прочитана. Лет 5 я этим успешно пользуюсь. В настоящее время привожу все к стандартам - не мешать интерфесы и объекты. Что нет так?

К мифической директиве мое отношение к соглашениями не имеет никакого дела... как минимум судя по дискуссии.


 
Суслик ©   (2004-09-07 15:56) [299]


> vuk ©   (07.09.04 15:54) [297]


> Вообще говоря, некоторые намеки есть в теме про COM Aggregation

Намеки есть - но до приведенного здесь вида далеко.


 
Romkin ©   (2004-09-07 15:59) [300]

Суслик ©   (07.09.04 15:47) [294] В доке по Delphi много чего нет, но это не значит, что это не надо знать :)))
Хорошо. Есть у меня задумка сделать набор интерфейсов для таблицы с данными (датасета, стринггрида и тд):
ITable - собственно таблица
IRecord - запись(строка) этой таблицы, у нее есть IField и тд...
С помощью каких классов VCL ты будешь реализовывать эти интерфейсы?
ТАк пойдет?
Дело в том, что вопросы, ответы на которые исчерпывающи в хелпе - понятно, посмотрел и все :)))


 
Ihor Osov'yak ©   (2004-09-07 16:00) [301]

2 [276] Акуличев Дмитрий   (07.09.04 15:16)

> Интерфейсы появились отнюдь не в COM.

Хм. Имнтерфейсы - как понятие - понятно. Но вот обладающими свойствами, перечислеными в [271], наследуемые от IUnknown? Или хотя бы без последнего условия?

Был бы благодарен за ссылку на источник информации.


 
vuk ©   (2004-09-07 16:01) [302]

to Суслик ©   (07.09.04 15:55) [298]:
>И вообще, чем тебе подход не нравится.
Зная основные правила работы с интерфейсами трудно дойти до ситуации, когда требуются директивы, которые создают проблем больше, чем решают.


 
Суслик ©   (2004-09-07 16:04) [303]


> Ihor Osov"yak ©   (07.09.04 16:00) [301]


> Был бы благодарен за ссылку на источник информации.

Я бы тоже...


> Romkin ©   (07.09.04 15:59) [300]

Не знаю - я не знаю vcl.
я никогда не пользовался ничем сложнее tedit.
все остальное свое.


 
Акуличев Дмитрий   (2004-09-07 16:05) [304]


> Суслик ©   (07.09.04 15:43) [292]
> Чтобы я вам троим поверил, найдите в документации по интерфейсам
> в дельфи и даже по COM в дельфи список этих требований.

А таблицу умножения в документации по Дельфи не найти?
А то непорядок, панимаш, целый тип есть, а таблицы умножения нету...


 
Суслик ©   (2004-09-07 16:06) [305]


> vuk ©   (07.09.04 16:01) [302]

Да ладно забей.
Проекту 5 лет. Начинал я его еще в универе, когда учился. Сейчас он успешно работает. А т.к. есть неотложные задачи, то руки не доходят. Просто ин-сы пришли не сразу - а как кобыле пятая нога. Постепенно избавляюсь.

Кстати, согласен с тем, что мифические директивы - это отстой.

А как вас еще поднять - молчите все в тряпочку :)))

А тут столько нового узнал: про соглашения, например.


 
Суслик ©   (2004-09-07 16:07) [306]


> Акуличев Дмитрий   (07.09.04 16:05) [304]

Зря язвишь :)
К вопросу отношения твоя реплика отношения не имеет.


 
Romkin ©   (2004-09-07 16:07) [307]

Суслик ©   (07.09.04 16:04) [303] Ну я уже тоже не знаю... Согласись, вопрос-то был про интерфейсы. Я уж и не знаю, что еще спросить-то...
Ну разве что о том, что за параметры у IDispatch.Invoke?


 
Суслик ©   (2004-09-07 16:12) [308]


> Ну разве что о том, что за параметры у IDispatch.Invoke?

:))) Лень смотреть.
Скажи, уважаемый, на фига он мне вообще сдался :))))
Я обхожусь без него вполне успешно.

Кстати, ты нашел - я до сих пор не знаю, что такое dispinerface, т.к. никогда не видел необходимости пользоваться :)))

Формально это не ключевое слова interface, но все же знать должен был бы :))))

Пошело домой ламерить.


 
Romkin ©   (2004-09-07 16:14) [309]

Суслик ©   (07.09.04 16:12) [308] Поздравляю. Скорее всего, ты не знаешь и TContainedObject & TAggregatedObject, а оне в System описаны :)
Кстати, вот строчка из дельфийского хелпа:
For more information about aggregation, controlling objects, and interfaces, see the Inside OLE, second edition, by Kraig Brockschmidt, the Microsoft Web site, or the Windows SDK Help.
:))))


 
Суслик ©   (2004-09-07 16:17) [310]


> Romkin ©   (07.09.04 16:07) [307]

Вообще на практическом использовании НЕдиспинтерфейсов тебе будет сложно меня поймать.

Дело в том, что я их весьма часто использую.

И фактически инкапсуляция частей программы реализована через них. В настоящий момент прорабатывается вынос одной части на сервер приложений. С транспортом пока не решено. Скорее всего будет свой.

Поэтому несмотря на то, что ин-сы можно было бы и не использовать, они все же используются для дальнейшего облегчения выделения сервера приложений. Пока приходится мириться с подмесом моделей инт. и об. Но это не надолго.

Поэтому сложно представить, что используя interface в крупном проекте я испытываю недостаток знаний.


 
Суслик ©   (2004-09-07 16:18) [311]


> Romkin ©   (07.09.04 16:14) [309]

Почему такой вывод. У меня половина проекта на них сделана.
Как это связано с dispinterface?


 
Ihor Osov'yak ©   (2004-09-07 16:19) [312]

2 Romkin ©   (07.09.04 15:45) [293]
> Да обычно и знать-то не надо.

С этим согласен вполне.

> Но если понадобится - запроси IUnknown и сравни два указателя :))

А вот это не факт. Вспоминаем агрегаты.  Давай на примере.
Есть некий обьект, поставляющий интерфейсы IA, IB, IC.
Естественно, он же предоставляет  IUnknown.

Я, как разработчик этого некого обьекта, знаю, что он IA реализовывает IA самостоятельно, а IB и IC агрегитирует у некоторых внутренних обьектов. Причем IB пердоставляет обьект oB, а IC реализовыватся oC. И что бы ты (как пользователь) не спрашивал у интерфейсов IC и IB - извне ты никак не узнаешь, что они агрегитированы и реализуются (хостятся) класами, отличными от класса, который хостит IA (oB и oC, а не oA).
Я это к тому, что вопрос "Реализуются ли все эти интерфейсы одним классом?"  в общем случае бессмысленный. Даже хотя бы потому, что сделать поддержку интерфейсов в принцыпе можно и за пределами обьекно-ориентированой парадигмы, даже средствами старого доброго чисто процедурного  кодирования.   И понятия там такого, как класс не будет вообще..

Если же говорить не об экземпляре класса, а о СOM-обьекте, то твой вопрос имет смысл.. И естественно, в таком случае задача решается сравнением IUnknown. Что с успехом и не единыжды уже делаю давно :-).

Ps. "Уточните значения слов - и вы избавите человечество от половины проблем". с. Декарт, кажется.


 
Romkin ©   (2004-09-07 16:21) [313]

Суслик ©   (07.09.04 16:18) [311] НУ никак не связана. Тогда ф удивлен, что ты не ответил на Romkin ©   (07.09.04 15:59) [300]
Прикалываешься?
И, кстати, откуда у тебя dispinterface всплыл? Я о нем не спрашивал ;)


 
Акуличев Дмитрий   (2004-09-07 16:22) [314]


> Ihor Osov"yak ©   (07.09.04 16:00) [301]
> 2 [276] Акуличев Дмитрий   (07.09.04 15:16)
>
> > Интерфейсы появились отнюдь не в COM.
>
> Хм. Имнтерфейсы - как понятие - понятно. Но вот обладающими
> свойствами, перечислеными в [271], наследуемые от IUnknown?
> Или хотя бы без последнего условия?
>
> Был бы благодарен за ссылку на источник информации.

Ссылок, боюсь, не дам. Дело в том, что эти требования не каким-то нормативным документом устанавливались, а вырабатывались в процессе исследований по проблемам открытых компонентных систем, когда стало очевидно, что для построения оных необходимо средство, ортогональное классическому ООП.
Так вот уж как-то получилось, что три постулата и одно следствие (у меня -- первый постулат) оказались минимальной непротиворечивой системой соглашений, удовлетворяющих требованиям к построению компонентных систем.

А вот наследование от IUnknown, кстати, необязательное требование, это уже особенности конкретной среды исполнения.


 
Суслик ©   (2004-09-07 16:26) [315]


> Romkin ©   (07.09.04 16:21) [313]
> Суслик ©   (07.09.04 16:18) [311] НУ никак не связана. Тогда
> ф удивлен, что ты не ответил на Romkin ©   (07.09.04 15:59)
> [300]
> Прикалываешься?


Нет, просто не знаю дельфовые компоненты Db. Совсем.


> И, кстати, откуда у тебя dispinterface всплыл? Я о нем не
> спрашивал ;)

сам не знаю.


 
Ihor Osov'yak ©   (2004-09-07 16:31) [316]

2 [314] Акуличев Дмитрий   (07.09.04 16:22)

> А вот наследование от IUnknown, кстати, необязательное требование, это уже особенности конкретной среды исполнения.

Это понятно, без вопросов..

> Ссылок, боюсь, не дам. Дело в том, что эти требования не каким-то нормативным документом устанавливались, а вырабатывались в процессе исследований по проблемам открытых компонентных систем, когда стало очевидно, что для построения оных необходимо средство, ортогональное классическому ООП.

Ну, в таком случае должны быть околонаучные публикации, какие-то рекомендации более-менее авторитетных коммисий...  Действительно интересно получить наводку на источник.

Хотя, действительно, я нигде не встречал утверждения о том, что интерфейсы - изобретение майкрософт.  Это на них не похоже. Если они что-то придумали - то обычно не стесняются это повторять. Еще - где-то читал что некое подобие идеологии интерфейсов в том смысле что класс имеет неснолько програмных интервейсов существует в яве. Но с явой я совершенно не знаком.


 
Суслик ©   (2004-09-07 17:42) [317]

Прошу прощения за подъем темы.
Это не повод продолжить обсуждение, а возможность для меня:
1) Поблагодарить всех за обсуждение. Честное слово - оно было продотворно.
2) Извиниться перед Акуличевым (если, конечно, его обидел) за пренебрежительное отношение к его любви к чтению.

Всем всего хорошего.

ЗЫ. Считаю, что холи вор кончилась весьма мирно, что радует.


 
Romkin ©   (2004-09-07 17:47) [318]

Ага. Я всегда говорил, что работа с СОМ в сях - полный отстой по сравнению с Delphi :))


 
GrayFace ©   (2004-09-07 17:56) [319]

Суслик ©   (06.09.04 20:08) [182]
Если ты пользуешься ansi строками, дин массивами и штатным манагером памяти обсолютно для всех целей, то о скорости говорить не приходится. Выигрышь в прибавлении чисел к поинтерам будет мал.

И даже не имхо.


Акуличев Дмитрий   (06.09.04 20:22) [192]
Меня больше необходимость этого для других типов интересует.


Для работы с массивами.

Игорь Шевченко ©   (06.09.04 21:36) [198]
Переведи пожалуйста свою глубокую мысль на понятный язык, можно на С++, можно на Delphi (это такой намек на пример в студию...)

Код в C: Return 12
Код в Delphi:
begin
 Result:=12;
 exit;
end;

Если бы была макроподстановка, можно было бы сделать макрос return.


> > Интерфейсов по-нормальному зделана в Java - там это
>вообще
> > не сущьность, а как-бы класс объекта, но без
>методов. COM-интерфейсы
> > для таких нужд мало пригодны, а множественное
>наследование
>> - очень даже.
>
> Опять же, поясни.

Ну если два потомка разных классов, сходны по функциональности.
И надо такое: В Java мы можем подать объект одного из этих классов в функцию, которая потом может не только работать с его интерфейсом, но и, например, удалить объект. В Delphi: Подаем функции интерфейс, а функция может общаться только с этим интерфейсом - объект ей не доступен(интерфейс as объект = ругань). Еще то, о чем говорит Суслик... Но я чуть-чуть знаком с интерфейсами. Я базируюсь на том, что это сущьность, отделенная от объекта.

> В ШКОЛУ!

Поздно уже. Я в универе на 1-м курсе.

> Чтобы перестать говорить чушь, открой окно CPU и
> посмотри генерируемый код.

Ну смотрите:


 
GrayFace ©   (2004-09-07 18:01) [320]

Удалено модератором
Примечание: Offtopic


 
Игорь Шевченко ©   (2004-09-07 18:01) [321]


> Код в C: Return 12
> Код в Delphi:
> begin
>  Result:=12;
>  exit;
> end;
>
> Если бы была макроподстановка, можно было бы сделать макрос
> return.


В школу.

Наличие слова Result в Delphi настолько облегчает жизнь, что return в C кажется крайне неудобным.


> Но я чуть-чуть знаком с интерфейсами.


Когда познакомишься поближе, я твое мнение с удовольствием выслушаю. Пока же - знакомься.


 
pasha_golub ©   (2004-09-07 18:15) [322]

Игорь Шевченко ©   (07.09.04 18:01) [321]
Наличие слова Result в Delphi настолько облегчает жизнь

Под каждым словом подписываюсь. Делал на заказ одному мальчику (студенту) лабораторки в ТП5. Писал сразу на листочке, и по привычке проставил везде


Result :=


Да это лана. Я удивляюсь добрости наших преподавателей, которые готовы подбросить соломинку студенту.

Сдача, препод подходит смотрит на код. "Запускайте", - говорит. Ясен пень, ошибка компиляции. "А, ну-ка покажите", - грит препод. Видит волшебные строки и радостно так, - "так вы оказывается на Делфе работали раньше?".

Студент недоуменно кивает, еще бы, ведь он думает, что Паскаль - это фамилия разработчика, а Борланд - имя, а тут...

Препод с довольной улыбкой ставит ему зачет. "Скромность украшает", - только и сказал он вдогонку.


 
Акуличев Дмитрий   (2004-09-07 18:16) [323]


> GrayFace ©   (07.09.04 17:56) [319]
> > Меня больше необходимость этого для других типов интересует.
>
> Для работы с массивами.

А, ну да. Индексация -- это для ламеров.


 
}|{yk ©   (2004-09-07 18:21) [324]

>Если бы была макроподстановка, можно было бы сделать макрос return.

Макросы приводят к таким сложноразберимым проблемам, конкретнее прочитай
Калверта С++Builder 5.0
А вот шаблоны, это да, очень прикольно. И STL мне в Delphi не хватает.


 
Игорь Шевченко ©   (2004-09-07 18:22) [325]

pasha_golub ©   (07.09.04 18:15) [322]


> Студент недоуменно кивает, еще бы, ведь он думает, что Паскаль
> - это фамилия разработчика, а Борланд - имя, а тут...


Имя у него Фрэнк, а фамилия Борланд :)


 
pasha_golub ©   (2004-09-07 18:24) [326]

Вообщем, благодаря Димону, за что ему спасибо огромное (без стеба), я узнал, что реализация интерфейсов построена на отношении (принципе) эквивалентности. Не знаю, как это можно в жизни использовать, но факт осознания собственной крутости меня разрывает. :0)

Ктстати, исходя из того что, все интерфейсы наследуются от IUnknown, получается что существует всего лишь один класс эквивалентности? Надо Думкина позвать, пусть обзовет или возвеличит. :)


 
pasha_golub ©   (2004-09-07 18:26) [327]

Игорь Шевченко ©   (07.09.04 18:22) [325]
О, а я не знал. А в рассказе имел в виду создателя Паскаля Клауса Вирта.


 
Nous Mellon ©   (2004-09-07 18:35) [328]

Я вот тут читаю, набираюсь уму разуму от спецов, но хотелось бы заступиться за господина Тимохова! Ну никак он не ламер. И даже не близко к ламеру. Я бы сказал быстро прогрессирующий профессионал! А как удар держит! Ему "ЛМД, Удавись" А он как железо. Вот настоящий профессионализм, уважаю. Я бы с таким собеседованием уж давно всех нах послал.


 
Игорь Шевченко ©   (2004-09-07 18:38) [329]

Nous Mellon ©   (07.09.04 18:35) [328]


> Я вот тут читаю, набираюсь уму разуму от спецов, но хотелось
> бы заступиться за господина Тимохова


А ты прочитай еще раз и внимательно...Можно два раза.


 
Nous Mellon ©   (2004-09-07 19:11) [330]


> А ты прочитай еще раз и внимательно...Можно два раза.

Спасибо что разрешили два раза прочитать, жаль эффекта не почувствовал :)


 
Agent13 ©   (2004-09-07 19:20) [331]


> Спасибо что разрешили два раза прочитать, жаль эффекта не
> почувствовал :)

repeat <читать ещё> until <появится эффект>;
Если эффект будет побочным, я не виноват.

P.S. Я тоже считаю, что Суслика зря обидели. Суслик - он хороший.


 
Nous Mellon ©   (2004-09-07 19:26) [332]


> repeat <читать ещё> until <появится эффект>;
> Если эффект будет побочным, я не виноват.

Конгениально!


 
GrayFace ©   (2004-09-07 19:51) [333]

Dok_3D ©   (07.09.04 7:50) [221]
Причем сразу в таких количествах и таком назидательном тоне, я минут пять смеялся.:)

Не знал, что этот тон назедателен.
Думкин ©   (07.09.04 7:05) [220]
А потом не постить стользабавный материал для орешника в столь значительных объемах.
Ну раз люди по 5 минут смеются, то, видимо, это достойно орешника. Я не против.

pasha_golub ©   (07.09.04 10:01) [224]
> Думкин ©   (07.09.04 07:05) [220]
> Сурово ты, однако. Сурово.
А я как-то не заметил.

Sergey_Masloff   (07.09.04 13:30) [233]
Обычно говорю да, С (С++, С#, VB - подставь по умолчанию) конечно намного круче.
VB? Visual Basic? Круче? Это как?

Romkin ©   (07.09.04 14:49) [256]
Дело в том, что реализация интерфейсов в Delphi и иерархия VCL для их поддержки - одна из лучших
Для своей цели. Суслику нажны не COM интерфейсы, а интерфейсы, просто характеризующие объект. Я с ним согласен - этого в Delphi не хватает. Но я не согласен в пути решения - это не должно иметь никакого отношения к теперешним интерфейсам Delphi.

Romkin ©   (07.09.04 14:59) [263]
1. Симетричность

Это "Коммутативность" по-научному.

Ihor Osov"yak ©   (07.09.04 15:04) [267]
Но ни один здравормыслящий не будет делать этого.

Один будет - Суслик. ;)

Romkin ©   (07.09.04 15:59) [300]
В доке по Delphi много чего нет, но это не значит, что это не надо знать :)))


Суслик ©   (07.09.04 16:12) [308]
Скажи, уважаемый, на фига он мне вообще сдался :))))
Я обхожусь без него вполне успешно.

Кстати, ты нашел - я до сих пор не знаю, что такое dispinerface, т.к. никогда не видел необходимости пользоваться :)))
Я написал калькулятор без теории вполне успешно (кажется), но на 600 постов :) Необходимость пониматся при таком подходе только когда уже поздно. Хотя необходимости тут и в помине нет, тут подходит только слово "пользя".

Ihor Osov"yak ©   (07.09.04 16:31) [316]
Еще - где-то читал что некое подобие идеологии интерфейсов в том смысле что класс имеет неснолько програмных интервейсов существует в яве. Но с явой я совершенно не знаком.

Там это заменяет множественное наследование, но интерфейс - абсолютно абстрактный набор методов, не имеющий своей реализации.

GrayFace ©   (07.09.04 18:01) [320]
Удалено модератором
Примечание: Offtopic

Никакой это не оффтопик. Вы удалили - теперь ИШ, наверное, спросит, что смотреть.

Игорь Шевченко ©   (07.09.04 18:01) [321]
Наличие слова Result в Delphi настолько облегчает жизнь, что return в C кажется крайне неудобным.

Дело вкуса. Вот было бы и то и другое - было бы хорошо, а так это спор немого со слепым, т.е. Holy War.
В общем, вам тоже в школу надо. :)


 
GrayFace ©   (2004-09-07 19:56) [334]

pasha_golub ©   (07.09.04 18:24) [326]
Надо Думкина позвать, пусть обзовет или возвеличит. :)

Он уже здесь.


 
Акуличев Дмитрий   (2004-09-07 20:10) [335]

Это животное настолько забавно, что мне даже не хочется его убить.


 
Игорь Шевченко ©   (2004-09-07 22:04) [336]

GrayFace ©   (07.09.04 19:51) [333]


> Я написал калькулятор без теории вполне успешно (кажется),


LOL

Полесов отдыхает.


> Дело вкуса. Вот было бы и то и другое - было бы хорошо


Вот мне интересно - как ты себе предстваляешь одновременно наличие переменной Result и оператора return (допустим, он появился в Delphi).


> Там это заменяет множественное наследование


Где это - там ?

(Ты тэги в следующий раз закрывай, а то не видно, где твои слова, а где чужие).


> В общем, вам тоже в школу надо.


Не потрудится ли достопоченный дон объяснить, почему именно мне надо в школу ? :)


 
Cobalt ©   (2004-09-07 22:21) [337]

2 Nous Mellon ©   (07.09.04 18:35) [328]
> А как удар держит!
Никак он не держит :(
Только он начинает понимать, что он не прав, как сразу же "Забей", или переводит тему. не получается у него пока проффесионализма признать собственные заблуждения :(

А GrayFace прямо-таки заставил посмеяться :-)

P.S. Решил я таки сегодня после такого бурного обсуждения плюнуть на Линукс и заняться изучением COM. Спасибо вам за это!


 
Nous Mellon ©   (2004-09-07 22:42) [338]


> Никак он не держит :(
> Только он начинает понимать, что он не прав, как сразу же
> "Забей", или переводит тему. не получается у него пока проффесионализма
> признать собственные заблуждения :(

Пока что ему никто толком не указал на его заблуждения. ИМХО конечно.


 
Nous Mellon ©   (2004-09-07 22:46) [339]


> В общем, вам тоже в школу надо. :)

АААА... Вот здесь и я рыдаю.. Что-то можно списать на возраст но отправить ИШ в школу это высший пилотаж, сильнее пожалуй только Дима О.


 
Gero ©   (2004-09-07 23:08) [340]


> GrayFace ©

Не по масти ты себе оппонентов для спора подобрал.


 
DiamondShark ©   (2004-09-07 23:17) [341]


> Игорь Шевченко ©   (07.09.04 22:04) [336]
> > GrayFace ©   (07.09.04 19:51) [333]
> > Я написал калькулятор без теории вполне успешно (кажется),
>
> LOL
> Полесов отдыхает.

Не могу удержаться, чтоб не процитировать:

Среди кустарей с мотором, которыми изобиловал Старгород, Виктор Михайлович Полесов был самым непроворным и чаще других попадавшим впросак. Причиной этого служила его чрезмерно кипучая натура. Это был кипучий лентяй. Он постоянно пенился. В собственной его мастерской, помещавшейся во втором дворе дома э 7 по Перелешинскому переулку, застать его было невозможно. Потухший переносный горн сиротливо стоял посреди каменного сарая, по углам которого были навалены проколотые камеры, рваные протекторы "Треугольник", рыжие замки-такие огромные, что ими можно было запирать города,– мягкие баки для горючего с надписями "Indian" и "Wanderer", детская рессорная колясочка, навеки заглохшая динамка, гнилые сыромятные ремни, промасленная пакля, стертая наждачная бумага, австрийский штык и множество рваной, гнутой и давленой дряни. Заказчики не находили Виктора Михайловича. Виктор Михайлович уже где-то распоряжался. Ему было не до работы. Он не мог спокойно видеть въезжающего в свой или чужой двор ломовика с кладью. Полесов сейчас же выходил во двор и, сложив руки за спиной, презрительно наблюдал действия возчика. Наконец, сердце его не выдерживало.

– Кто же так заезжает?-кричал он ужасаясь.Заворачивай! Испуганный возчик заворачивал.

– Куда же ты заворачиваешь, морда?– страдал Виктор Михайлович, налетая на лошадь.– Надавали бы тебе в старое время пощечин, тогда бы заворачивал.

Покомандовавши так с полчаса. Полесов собирался было уже возвратиться в мастерскую, где ждал его непочиненный велосипедный насос, но тут спокойная жизнь города обычно вновь нарушалась каким-нибудь недоразумением. То ка улице сцеплялись осями телеги, и Виктор Михайлович указывал, как лучше всего и быстрее их расцепить, то меняли телеграфный столб, и Полесов проверял его перпендикулярность к земле собственным, специально вынесенным из мастерской отвесом; то, наконец, проезжал пожарный обоз, и Полесов, взволнованный звуками трубы и испепеляемый огнем беспокойства, бежал за колесницами.

Однако временами Виктора Михайловича настигала стихия реального действия. На несколько дней он скрывался в мастерскую и молча работал. Дети свободно бегали по двору и кричали что хотели, ломовики описывали во дворе какие угодно кривые, телеги на улице вообще переставали сцепляться, и пожарные колесницы и катафалки в одиночестве катили на пожар-Виктор Михайлович работал. Однажды, после одного такого запоя, он вывел во двор, как барана за рога, мотоцикл, составленный из кусочков автомобилей, огнетушителей, велосипедов и пишущих машинок. Мотор в полторы силы был вандереровский, колеса давидсоновские, а другие существенные части уже давно потеряли фирму. С седла свисал на шпагатике картонный плакат "Проба". Собралась толпа. Не глядя ни на кого, Виктор Михайлович закрутил рукой педаль. Искры не было минут десять. Затем раздалось железное чавканье, прибор задрожал и окутался грязным дымом. Виктор Михайлович кинулся в седло, и мотоцикл, забрав безумную скорость, вынес его через туннель ка середину мостовой и сразу остановился, словно срезанный нулей. Виктор Михайлович собрался было уже слезть и обревизовать свою загадочную машину, но она дала вдруг задний ход и, пронеся своего создателя через тот же туннель, остановилась на месте отправления-посреди двора, ворчливо ахнула и взорвалась. Виктор Михайлович уцелел чудом и из обломков мотоцикла в следующий запойный период устроил стационарный двигатель, который был очень похож на настоящий, но не работал.


 
Игорь Шевченко ©   (2004-09-07 23:40) [342]

DiamondShark ©   (07.09.04 23:17) [341]

У меня просто дома в электронном виде "12 стульев" нету, большое спасибо за цитату :)


> Виктор Михайлович уцелел чудом и из обломков мотоцикла в
> следующий запойный период устроил стационарный двигатель,
> который был очень похож на настоящий, но не работал.


Калькулятор тоже похож на настоящий...


 
имя   (2004-09-08 07:57) [343]

Удалено модератором


 
Игорь Шевченко ©   (2004-09-08 10:16) [344]

Профи   (08.09.04 07:57) [343]

А ты на название сайта посмотри. Можно два раза.


 
имя   (2004-09-08 10:41) [345]

Удалено модератором


 
Игорь Шевченко ©   (2004-09-08 10:45) [346]

Профи   (08.09.04 10:41) [345]


> Акцент не на "о чем", а на том "сколько" и "воду в ступе".


А нельзя ли поподробнее осветить, почему воду в ступе ? Ей-богу, интересно.


 
Суслик ©   (2004-09-08 10:50) [347]


> Nous Mellon ©   (07.09.04 22:42) [338]


> Пока что ему никто толком не указал на его заблуждения.
> ИМХО конечно.

Спасибо, друг, ты один из немногих, кто внимательно читает прежде чем делать выводы.

Меня обидеть сложно, а тем более расстроить.
Однако ж было как-то - вывел меня препод по матану к доске, и так зачмырил (заслуженно), что учится пришлось. И даже результат был.

Офлайновое общение, как я понял, не располагает к пониманию. Оно располагает к развлечениею. У всех оно разное. Не буду перечислять у какого какое - вроде и так понятно. У меня тоже оно есть :)


 
Суслик ©   (2004-09-08 10:56) [348]


> Cobalt ©   (07.09.04 22:21) [337]


> Только он начинает понимать, что он не прав, как сразу же
> "Забей"

А что мне делать? Зачем дальше нагревать обстановку? Не я решаю жить или не жить посту - а при недопонимании друг-друга сохранять самообладание сложно, каюсь.


 
0d08h   (2004-09-08 10:56) [349]

Профи  
во первых форум Потрепатся(тут тоже свои правила)
во вторых тут затронуты религиозные чувства(те кому больше нравится пмсать на Паскале свято верит в то что Паскаль панацея от всего те кому больше нравится С те уверены что С панацея вот и воюют)


 
Думкин ©   (2004-09-08 10:58) [350]

>  [349] 0d08h   (08.09.04 10:56)

Это не так - слишком поверхностно.


 
Суслик ©   (2004-09-08 10:58) [351]


> 0d08h   (08.09.04 10:56) [349]


> во вторых тут затронуты религиозные чувства

Разве? :) Мне казалось, что обсуждаются конкретные структуры языков и их семантическое наполнение... Кто как, а я считаю такое полезно пообсуждать. Многие, в том числе и я, узнали новое. Религии как мне кажется здесь места нет.


 
0d08h   (2004-09-08 11:11) [352]

Суслик
Сама тема holy war уже не один десяток лет я об этом еще спорил в 1998 году


 
имя   (2004-09-08 11:14) [353]

Удалено модератором


 
Agent13 ©   (2004-09-08 11:19) [354]


> Сама тема holy war

Это точно. И вот что интересно - для того, чтобы люди начали холиворить совсем необязательно сравнивать что-то с чем-то - там Делфи с Сями, Интел с АМД и пр. Достаточно попросить, скажем назвать достоинства и недостатки тех же делфей, не заикаясь о других языках. Если только тема предполагает высказываться "за или против", обсуждение практически гарантированно закончится хамством. Видимо такова уж натура человеческая.


 
Суслик ©   (2004-09-08 11:20) [355]


> цитат с сайтов и форумов, вырванных с яндекса.

Ну это ты зря - тут люди серьезные.


 
Romkin ©   (2004-09-08 11:20) [356]

По аське пришло:
Кстати реальный случай в МиФи недавно призащёл:
Лекция по Архитектуре ОС.
Маленький, щуплый лектор (подпольная кличка Покимон), весело и радостно рассказывает о Unix.
- И теперь. господа, запишем почему Unix стал таким популярным, почему, написаный энтузиастами он конкурирует с таким монстром как MicroSoft... А потаму что написан он был на Си а это значит что? (слышится слабое лепетание с первой парты) Правильно, объём увеличивается, скорость замедляется....


 
Суслик ©   (2004-09-08 11:21) [357]


> за или против", обсуждение практически гарантированно закончится
> хамством

Ну хамство, скажем искреннее спасибо модератору, пресекалось и к концу практически не было...


 
Romkin ©   (2004-09-08 11:23) [358]

Суслик ©  (08.09.04 11:21) [357] Так ты еще и хамил?! :)))
Ламерррр!


 
Суслик ©   (2004-09-08 11:26) [359]

Когда я учился на пятом курсе дельфи 2 или 3 только появилась.
На одной из лекций сзади сидел "профи" (или может даже без кавычек). Я его знал, он уже тогда серьезно работал. Причем писал на плюсах. Как и в любом деле у каждого профи есть поклонники. У него их было человека два - слова аж записывали. И вот однажды слышу как он сравнивает дельфи и плюсы. При том - ни одного факта правды про дельфи.

1) В дельфи фукнции обязательно должны возвращать резульатат - вернее при вызове функции ее результат нужно чему-то присваивать.
2) Типа в дельфи указателей нет, вернее нельзя к ним прибавлять значения.
и пр.

Весело было его послушать.


 
Суслик ©   (2004-09-08 11:28) [360]


> Romkin ©   (08.09.04 11:23) [358]

вот кстати вопрос чисто по интерфейсам:
как при передачи интерфейса в качестве параметра в метод управлять механизмом подсчета ссылок?


 
Romkin ©   (2004-09-08 11:29) [361]

Кстати, возвращаясь к нашим баранам, "удобству" вызова Invoke мы обязаны, как ни смешно, визуалбейсиковцам :(
Дело в том, что в VB исторически сложилось, что, например, процедуру proc(A,B,C) можно вызвать:
proc(1,2,3) и proc(1,,3) и, главное, proc(B=2,C=3,A=1).
И теперь, даже вызывая Invoke из С, вы должны подать не только массив входных значений, но еще и массив соответствующих имен этих параметров (и, эссно, имена должны знать)
:)))


 
Danilka ©   (2004-09-08 11:30) [362]

Так все-таки, что лучше, Дельфи или С++?
А то, наговорили ужо за три сотни с половиною, а так и непонятно, что-же лучше.

;)


 
Romkin ©   (2004-09-08 11:31) [363]

Суслик ©  (08.09.04 11:28) [360] Если параметр имеет тип интерфейс - делать ничего не нать. Если поинтер - плиз, addref/release сам делай.


 
Romkin ©   (2004-09-08 11:31) [364]

Danilka ©  (08.09.04 11:30) [362] Лучше тот язык, который ты знаешь. Все остальное - суета сует и протчая...


 
Danilka ©   (2004-09-08 11:33) [365]

[364] Romkin ©   (08.09.04 11:31)
Эт я и сам знаю, лучче PL/SQL ничего нет.
Мне просто интересно, итог у ветки будет или нет.
:))


 
Суслик ©   (2004-09-08 11:33) [366]


> Romkin ©   (08.09.04 11:31) [363]

я не говорю, что нать, а что не нать.

Вопрос: как можно?


 
Суслик ©   (2004-09-08 11:34) [367]


> Romkin ©   (08.09.04 11:29) [361]

Дай что-нить почитать про invoke.
Когда я хармона читал, я это как-то пропустил, т.к. не понял - в тот момент мне это показалось ненужным, может и зря.


 
Суслик ©   (2004-09-08 11:35) [368]


> Мне просто интересно, итог у ветки будет или нет.
> :))

Конечно - ее закроют.


 
0d08h   (2004-09-08 11:38) [369]

Danilka
Лучше то что ты лучше умееш использовать.
Все остальное суета сует и сметение духа.


 
Акуличев Дмитрий   (2004-09-08 11:39) [370]


> И теперь, даже вызывая Invoke из С, вы должны подать не
> только массив входных значений, но еще и массив соответствующих
> имен этих параметров

А вот и неправда.


 
Danilka ©   (2004-09-08 11:39) [371]

[369] 0d08h   (08.09.04 11:38)
Дык, а если я ни дельфи ни ц++ низнаю, что делать-то?
Хотел здеся разобрацца, а вижу один оффтопик - интерфейсы, причем здесь лучше/нелучше? :))


 
Romkin ©   (2004-09-08 11:40) [372]

Суслик ©  (08.09.04 11:33) [366] Ну как? хочешь отключить автомат - преобразуй к pointer :))
Суслик ©  (08.09.04 11:34) [367] Хм... Ищи книгу "СОМ и ATL" вроде, толстая такая. Там - практически все :)) Но на С++. Но зато понимаешь, что и как работает. Половина книги - программирование СОМ на С++ без ATL - эт фундаментально. Знакомый хвастался, что по ней сделал класс, реализующий полностью IDispatch без ATL. Мдя... 15 кило текста :)))
Ну и рекомендация Borland уже была:
For more information about aggregation, controlling objects, and interfaces, see the Inside OLE, second edition, by Kraig Brockschmidt, the Microsoft Web site, or the Windows SDK Help.


 
Суслик ©   (2004-09-08 11:41) [373]


> Danilka ©   (08.09.04 11:39) [371]

Забей - не разберешься.
Учи оба языка и дело с концом. Какой не понравится срочно забудешь.


 
Суслик ©   (2004-09-08 11:42) [374]


> Romkin ©   (08.09.04 11:40) [372]
> Суслик ©  (08.09.04 11:33) [366] Ну как? хочешь отключить
> автомат - преобразуй к pointer :))

это один из способов,
второй
procedure proc(const i: IMyIntf);


 
Romkin ©   (2004-09-08 11:43) [375]

Суслик ©  (08.09.04 11:34) [367] Но чисто вызов invoke со сборкой параметров - нафиг :) В Delphi уже написано...


 
0d08h   (2004-09-08 11:43) [376]

Danilka
Учи Паскаль он проще только не дай бог не Дельфи с нуля именно Паскаль.
Есть такая книженция К. Боон "Паскаль для всех" 1983 г. по нему можно кого угодно научить сам с нее начинал


 
Romkin ©   (2004-09-08 11:44) [377]

Суслик ©  (08.09.04 11:42) [374] А. Да, не должен вроде. Если так - то хорошо. Но мне до сих пор ни разу не понадобилось управлять подсчетом ссылок :))
Нет, вру, один раз, когда интерфейсы вставлял в список как указатели...


 
Danilka ©   (2004-09-08 11:45) [378]

[373] Суслик ©   (08.09.04 11:41)
В том-то и дело, что учил оба, а теперь уже оба забыл. Горе-то какое. А учить оба заново - низя - старый я, память уже не та.

Порошу модераторов изничтожить весь оффтопик! Пусть лучше здесь крутые распальцованые перцы разбираюцца, что есть рулез, а что есть зло, а обсуждателей интерфейсов выгнать в другую ветку. Вот-так!

:))


 
Суслик ©   (2004-09-08 11:45) [379]


> Romkin ©   (08.09.04 11:43) [375]

Если я ошибаюсь - к раннему связыванию это отношения не имеет?


 
Акуличев Дмитрий   (2004-09-08 11:45) [380]


> Суслик ©   (08.09.04 11:42) [374]
> второй
> procedure proc(const i: IMyIntf);

Это не отключает подсчёт ссылок.


 
Суслик ©   (2004-09-08 11:47) [381]


> Romkin ©   (08.09.04 11:44) [377]

не может быть, а точно.
это я так, для информации сказал.


> Danilka ©   (08.09.04 11:45) [378]

Ага :))) Когда я читал Рихтера, я тоже вспомнил, что его читал - лет 5 назад, только прошлое издание :)))) Типа того?
ТАкого не бывает - если учил, забыть нельзя.


 
Суслик ©   (2004-09-08 11:47) [382]


> Акуличев Дмитрий   (08.09.04 11:45) [380]


> Это не отключает подсчёт ссылок.

А ты проверь?


 
Romkin ©   (2004-09-08 11:52) [383]

Суслик ©  (08.09.04 11:45) [379] Конечно. Позднее потому и называется так, что все вызовы идут через invoke


 
Суслик ©   (2004-09-08 11:53) [384]


> Romkin ©   (08.09.04 11:52) [383]

вот, а про позднее я ничего и не знаю.
А для чего ты его используешь если НЕ для ком?


 
Romkin ©   (2004-09-08 11:54) [385]

Суслик ©  (08.09.04 11:53) [384] Что значит НЕ для СОМ? Я кроме СОМ ничем и не пользуюсь :)


 
Суслик ©   (2004-09-08 11:55) [386]


> Акуличев Дмитрий   (08.09.04 11:45) [380]

В зависимости от const в начале метода либо будет
00452381 E8363CFBFF       call @IntfAddRef
либо
нет

Проверь, только что посмотрел.


 
Суслик ©   (2004-09-08 11:55) [387]


> Romkin ©   (08.09.04 11:54) [385]

значит мне сейчас это не надо.


 
Romkin ©   (2004-09-08 12:05) [388]

Суслик ©  (08.09.04 11:55) [387] НУ наверно можно, конечно, чделать свой транспорт и делать удаленные вызовы - к другому процессу, например. Но нафига, если все уже в СОМ сделано.
Сейчас не надо - может быть. Но СОМ я посоветовал бы изучить, как только входишь во вкус...
Когда тебе не важно, где именно находится объект, ты им просто пользуешься, да еще вся информания записана сразу в нем :))
Да и просто применению интерфейсов помогает, понимаешь, какие методы и какие классы должны быть


 
Суслик ©   (2004-09-08 12:09) [389]


> Romkin ©   (08.09.04 12:05) [388]

КОМ наверное прийдется изучать.

При том, что как писать КОМ в дельфи я в общем-то знаю. В проекте есть пара объектов. Но, согласен, все это на уровне понимания внешний проявлений и правил использования.

С тем, что ком помогает пониманию интерфейсов позволь несогласится. Хотя, стоит проверить.


 
Акуличев Дмитрий   (2004-09-08 12:15) [390]


> Суслик ©   (08.09.04 11:55) [386]

Если параметр не конст, то он внутри процедуры обрамляется дополнительной парой addref/release. Если он конст -- то нет.
Но это не значит, что вообще не ведётся подсчёт ссылок.
В зависимости от того, что происходит внутри процедуры компилятор будет вызывать addref/release там, где это надо.


 
Суслик ©   (2004-09-08 12:18) [391]


> Акуличев Дмитрий   (08.09.04 12:15) [390]


> В зависимости от того, что происходит внутри процедуры компилятор
> будет вызывать addref/release там, где это надо.

В этом ты абсолютно прав. Я утвержал/спрашивал обратное?

>>как при передачи интерфейса в качестве параметра в метод управлять механизмом подсчета ссылок?


 
GRAND25 ©   (2004-09-08 12:21) [392]

Все хорошо, только причем тут Делфи и С++? Ветка вроде бы об этом, а не о легкости программирования междумордий.

Поэтому пишу по сабжу: оба обсуждаемых языка хороши, помиритесь.

Долой Спартак!


 
Суслик ©   (2004-09-08 12:24) [393]


> GRAND25 ©   (08.09.04 12:21) [392]

здесь уже постов 200 оффтоп :)))
про дельфи и си уже никто вроде не спорит.


 
Акуличев Дмитрий   (2004-09-08 12:25) [394]


> Суслик ©   (08.09.04 12:18) [391]
> >>как при передачи интерфейса в качестве параметра в метод
> управлять механизмом подсчета ссылок?

Ну если так, то ответ -- никак.

Модификатор параметра управляет механизмом подсчёта не при передаче, а внутри процедуры.

Вот такой я злой занудный формалист ;)


 
Акуличев Дмитрий   (2004-09-08 12:27) [395]


> про дельфи и си уже никто вроде не спорит.

Да кому этот си нуфиг нужен...


 
Суслик ©   (2004-09-08 12:34) [396]


> Акуличев Дмитрий   (08.09.04 12:25) [394]

Ой, улыбнулся! Ну радостно :))

Все же тут надо внести ясность.
Если внутри процедуры вызывать методы ин-са и в случае const никакого подсчета ссылок не будет.

Т.е. если написать const и не присваивать внутри метода интерфейс, то можно сказать, что мы смогли направить механизм согласно моему вопросу - ни разу за время работы методы addref не изменится.


 
euru ©   (2004-09-08 12:38) [397]

Насколько я знаю, посчёт ссылок ведётся только в СОМ и в реализации интерфейсов в Delphi (там их изначально под COM подгоняли).
В Java и CORBA, если я не ошибаюсь, этого нет.
Кстати, в .Net вроде бы тоже уже не упоминается AddRef, ReleaseRef и QueryInterface.


 
Игорь Шевченко ©   (2004-09-08 12:41) [398]

Акуличев Дмитрий   (08.09.04 12:27) [395]


> Да кому этот си нуфиг нужен...


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


 
Суслик ©   (2004-09-08 12:46) [399]

Можно поднять еще один вопрос о дельфи?

Наверное все знают, что есть такие функции finalize и initialize и все знают, что они делают.
Это очевидный compile magic.
Вы не найдете явного их объявления нигде - их или их аналоги вставляет компилятор в код.
Фактически они эксивалетны _finilize и _initialize из system.
Рядом с _finilize есть _AddRef. Который понятно , что делает из названия.

Вопрос: Почему _AddRef не вынесен в доступную фукнкция, как это сделано для finlize и initilize? Как вы думаете, в чем причины?


 
Акуличев Дмитрий   (2004-09-08 12:55) [400]


> Сколько же ежиков плачут, колются, но продолжают грызть
> кактус :)

А ещё миллион мух не может ошибаться.
:)


 
MU ©   (2004-09-08 12:58) [401]

Хочу отметить еще один вопрос - мнение (психология) заказчиков...
казалось бы, им д.б. все равно на чем написан проект, главное, чтобы он работал и выполнял все необходимые функции.
был у нас большой проект на FoxPro DOS - много успешных внедрений и проч., но со временем стали раздаваться голоса, что это вчерашний день, что виндоуз это - круто и т.д. хотя кассиру или бухгалтеру ведь все равно DOS это или Windows, им надо чтобы цифры были правильные.
Перешли на Дельфи. теперь нет-нет да и слышится от заказчиков-руководителей: "на дельфи серьезные проекты не пишутся, .NET, C# и прочий набор где-то услышанных ими звуков".


 
Акуличев Дмитрий   (2004-09-08 12:59) [402]


> Суслик ©   (08.09.04 12:46) [399]
>
> Вопрос: Почему _AddRef не вынесен в доступную фукнкция,
> как это сделано для finlize и initilize? Как вы думаете,
> в чем причины?

Как же не вынесен, если это часть любого интерфейса?
Название с чёрточкой смущает?


 
Игорь Шевченко ©   (2004-09-08 13:05) [403]

Акуличев Дмитрий   (08.09.04 12:55) [400]


> А ещё миллион мух не может ошибаться.


Эт к Visual Basic :))


 
jack128 ©   (2004-09-08 13:12) [404]

Суслик ©   (08.09.04 12:46) [399]
Вопрос: Почему _AddRef не вынесен в доступную фукнкция, как это сделано для finlize и initilize? Как вы думаете, в чем причины

А если не секрет зачем?? Где используется initialize/finalize я себе представляю, а вот зачем нужен явный вызов _AddRefArray не очень..


 
Акуличев Дмитрий   (2004-09-08 13:13) [405]


> Игорь Шевченко ©   (08.09.04 13:05) [403]
> Эт к Visual Basic :))

Нет. Эт к ссылкам на большинство как авторитет.


 
jack128 ©   (2004-09-08 13:16) [406]

jack128 ©   (08.09.04 13:12) [404]
кстати, про интерфейсы вы тут вроде разобрались ;-) а формат строк/дин массивов расписан, коль жить надоело, можешь сам использовать их счетчик ссылок ;-)


 
Димитрий ©   (2004-09-08 13:35) [407]

А еще в последнее время набирает популярность язык программирования BrainFuck :)


 
Акуличев Дмитрий   (2004-09-08 13:42) [408]


> А еще в последнее время набирает популярность язык программирования
> BrainFuck :)

А ещё есть язык, у которого весь алфавит состит только из символов
#9 #10 #12 #13 #32
Забыл только как называется.


 
Суслик ©   (2004-09-08 13:59) [409]


> Акуличев Дмитрий   (08.09.04 12:59) [402]

Ты не просек, про что я.
_AddRef это не из интерфейсов - это функция в system... посмотри - рядом с _initilize.

под невынесенностью я понимаю недокументированность.


> jack128 ©   (08.09.04 13:12) [404]
> Суслик ©   (08.09.04 12:46) [399]
> А если не секрет зачем?? Где используется initialize/finalize
> я себе представляю, а вот зачем нужен явный вызов _AddRefArray
> не очень..

Для копирования больших кусков памяти.

Например - есть record с длинными строками. Тебе нужно его скопировать. Хорошо было бы move + addref. Конечно, для записей это можно и так сделать - просто присваиваньшем. Но существуют задачи, где было бы нужно анонимно копировать область памяти конечно зная ее typeInfo.


 
Суслик ©   (2004-09-08 14:00) [410]


> jack128 ©   (08.09.04 13:16) [406]

зачем мне самому лезть в формат строк и дин масивов.
есть addref, только вызывать ее надо без параметров.
теоретически это можно (я даже пробовал).
мне непонятно почему эта ф-я недокументирована.


 
имя   (2004-09-08 14:12) [411]

Удалено модератором


 
Ihor Osov'yak ©   (2004-09-08 14:13) [412]

> мне непонятно почему эта ф-я недокументирована.

По той же причине, почему не нужно вмешиваться в процесс управления жызнью обьектов, хостящих интерфейсы.

Зы.. Я уже приводил цитату, относительно програмированния под платформу майкрософт и соблюдения рекомендаций майкрософт.. Немного перефразируете его относительно программирования с использованием инструментария борланда и рекомендаций борланда. Я имею ввиду о работе с обьектами с управляемым временем жызни.

Зы2. Вы бы лучше хорошо разобралисть с тем, что уже есть, а потом бы велосипед изобретали... Да, кстати, как подсказывает жизненный опыт - чем больше знаешь, тем реже возникает потребность и желание изобретать велосипед.


 
Суслик ©   (2004-09-08 14:18) [413]


> Ihor Osov"yak ©   (08.09.04 14:13) [412]
По той же причине, почему не нужно вмешиваться в процесс управления жызнью обьектов, хостящих интерфейсы.


Все опнятно.
Зачем тогда initilize и finilize документированы?
чем они концептуально отличаются от system._addref?

Очень прошу - не отвечайте общими словами.
Вопрос то в общем весьма конкретный.

ЗЫ. Еще огромная просьба - сбавить назидательность. Ранее я поблагодарил тебя за продуктивную дискуссию. Чрезвычайно был бы рад и благодарен, если бы мне не пришлось менять свое мнение.
:)) Если уж я справшиваю, то наверное разобрался? :)

ЗЗЫ. Из того, что вы до сих пор говрите про интерфейсы делаю вывод, что был непонят исходный вопрос. См. system по строке поиска _initialize и ниже на 4-5 строк - функция _addref.


 
vuk ©   (2004-09-08 14:19) [414]

to Ihor Osov"yak ©   (08.09.04 14:13) [412]:
>По той же причине, почему не нужно вмешиваться в процесс
>управления жызнью обьектов, хостящих интерфейсы.
Вмешиваться иной раз все-таки нужно. Но только делать это нужно с полным пониманием происходящего.


 
Суслик ©   (2004-09-08 14:20) [415]


> vuk ©   (08.09.04 14:19) [414]
Вмешиваться иной раз все-таки нужно. Но только делать это нужно с полным пониманием происходящего.


Во-во.
Именно для вмешательства и существуют (в частности) initilize и finilize. Вот весь вопрос, почему нет addref?


 
KSergey ©   (2004-09-08 14:21) [416]

> [413] Суслик ©   (08.09.04 14:18)
> Зачем тогда initilize и finilize документированы?
> чем они концептуально отличаются от system._addref?

Прощу прощения, а скажите, почему они в один ряд встали? initilize и finilize - одно. А addref при чем тут? Или обобщаем понятия объект/модуль?

А еще такой вопрос: почему (Д5, если критично) нельзя написать finilize без initilize??


 
Суслик ©   (2004-09-08 14:23) [417]


> KSergey ©   (08.09.04 14:21) [416]

вы совсем не о том
initialize + f1


 
Суслик ©   (2004-09-08 14:30) [418]

Чую интузиазма у участников нет.

Вообще initilize/finalize кто-нить пользуется?


 
vuk ©   (2004-09-08 14:32) [419]

to Суслик ©   (08.09.04 14:20) [415]:
>Во-во.
Я говорил только про интерфейсы.


 
Суслик ©   (2004-09-08 14:36) [420]


> vuk ©   (08.09.04 14:32) [419]

А про все остальное: строки, дин. массивы и пр., варианты?
Там не надо вмешиваться?
Зачем же тогда документированы initilize/finilize?
Я бы может и сам был бы рад не пользоваться, но такая хорошая документированная фича. Да и сами ребята из борланда где-то видел этим пользуются.

Ты сам пользуешься initilize/finilize?


 
KSergey ©   (2004-09-08 14:37) [421]

> [417] Суслик ©   (08.09.04 14:23)

Прошу прощения. Сильно я ляпнул ;)


 
jack128 ©   (2004-09-08 14:37) [422]

Суслик ©   (08.09.04 14:30) [418]
Вообще initilize/finalize кто-нить пользуется?

я иногда. Но редко. Только потому, что их использование навязывает сторонний компонент..


 
Акуличев Дмитрий   (2004-09-08 14:37) [423]


> Но существуют задачи, где было бы нужно анонимно копировать
> область памяти конечно зная ее typeInfo.

Приводи типы и будет тебе щасье.


 
Суслик ©   (2004-09-08 14:41) [424]


> Акуличев Дмитрий   (08.09.04 14:37) [423]
Приводи типы и будет тебе щасье.

Иногда так и делаю. Это не всегда удобно.

Например надо очистить элементы массива variant с 10 по 20. Можно пробежаться и присвоить им всем null иди unassigned, например. А можно вызывать

finlize(a[10]^, 11);


 
Суслик ©   (2004-09-08 14:41) [425]

виноват

> finlize(a[10]^, 11);

finlize(a[10], 11);


 
Игорь Шевченко ©   (2004-09-08 14:43) [426]


> Например надо очистить элементы массива variant с 10 по
> 20. Можно пробежаться и присвоить им всем null иди unassigned,
> например. А можно вызывать
>
> finlize(a[10]^, 11);


А через пару месяцев поиметь проблемы на тему: "а что же я написал"


 
Суслик ©   (2004-09-08 14:46) [427]


> А через пару месяцев поиметь проблемы на тему: "а что же
> я написал"

Кому поиметь? Мне?
Повторю - это документированная функция.
Я не поимею. Другой? Нажми ф1.

Была бы недокументированная - не в жизь не пользовался бы - никогда так не делаю.


 
Акуличев Дмитрий   (2004-09-08 14:48) [428]


> Суслик ©   (08.09.04 14:30) [418]
> Чую интузиазма у участников нет.
>
> Вообще initilize/finalize кто-нить пользуется?

Я пользовался. Когда хранил в TList записи со строками.

Дело в том, что необходимость в Initialize/Finalize я вижу. А вот в ручном управлении счётчиком -- нет.


 
Акуличев Дмитрий   (2004-09-08 14:53) [429]


> Зачем же тогда документированы initilize/finilize?

Там где они документированы, там же и написано зачем.

Initialize should be used only in situations where a variable is dynamically allocated by other means than the New standard procedure.

Finalize should be used only in situations where a dynamically allocated variable is deallocated by other means than the Dispose procedure.


 
Суслик ©   (2004-09-08 14:53) [430]


> Акуличев Дмитрий   (08.09.04 14:48) [428]


> Дело в том, что необходимость в Initialize/Finalize я вижу.
> А вот в ручном управлении счётчиком -- нет.

Уточню ответ:
Наверное так
"А вот в ручном управлении счётчиком интерфейсов -- нет."
Да?

Т.е. для строк, например, видишь?
Не могу понять в чем для тебя разница.

Ну представь себе, что я в интерфейса вижу "плодотворную идею" саму по себе без привязки к com. Более того, я не только вижу, но и применяю такое видение, о чем пока пожалеть не пришлось.

Вот скажи с обозначенной выше точки зрения - чем для меня отличается скажем строка и интерфейс с точки зрения управления их жизнью?


 
Danilka ©   (2004-09-08 14:55) [431]

[430] Суслик ©   (08.09.04 14:53)
> Т.е. для строк, например, видишь?

Хм, а для строчек-то зачем? Просто интересно..


 
Суслик ©   (2004-09-08 14:56) [432]


> Акуличев Дмитрий   (08.09.04 14:53) [429]


> Там где они документированы, там же и написано зачем.

Ну знаешь ли, читать и я могу.

Почему бы не документировать (тем более, что она есть и хорошо работает) такую функцию: addref.

С такой докой:

AddRef should be used only in situations where a variable copied by other means than by ":=".

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


 
Игорь Шевченко ©   (2004-09-08 14:57) [433]

Суслик ©   (08.09.04 14:46) [427]


>  Нажми ф1.


Нажал. "The word you have typed is not in the index".


 
Суслик ©   (2004-09-08 15:01) [434]


> Danilka ©   (08.09.04 14:55) [431]

сначала пример
type
  PRec = ^TRec;
  TRec = record
     s: string;
  end;
var
  p: PRec;
begin
  GetMem(p, SizeOf(TRec));
  p^.s := stringof("0", 10);
  Finalize(p^); // без этого будет учечка - s не освободится.
  FreeMem(p);
end;

зачем это нужно?
Представь, что реализуешь например свой датасет. Понятно, что при серьезной разработке ни вариантами, ни строками пользоваться нельзя - надо их эмулировать более оптимально. НО для реализации чего-то внесколькократно быстрого чем tclientdataset вполно можно пользоваться и AnsiString. Для того, чтобы быстро очищать боласти памяти нужно исползовать finalize.


 
Суслик ©   (2004-09-08 15:02) [435]

>>Игорь Шевченко ©   (08.09.04 14:57) [433]
Ты имеешь в виду очепатку?
Ну-ну
тогда жми f1 на строке finalize :)))))


 
Акуличев Дмитрий   (2004-09-08 15:03) [436]


> Суслик ©   (08.09.04 14:53) [430]
>
> > Акуличев Дмитрий   (08.09.04 14:48) [428]
>
>
> > Дело в том, что необходимость в Initialize/Finalize я
> вижу.
> > А вот в ручном управлении счётчиком -- нет.
>
> Уточню ответ:
> Наверное так
> "А вот в ручном управлении счётчиком интерфейсов -- нет."
> Да?

Чяво? Мы же вроде бы уже про структурированные типы говорим.


> Вот скажи с обозначенной выше точки зрения - чем для меня
> отличается скажем строка и интерфейс с точки зрения управления
> их жизнью?

Ничем. Я про это всю дорогу и толкую.

Мне не надо управлять временем жизни.
Кроме особо специальных случаев. Которые, в свою очередь, полностью покрываются приведением типов.
Зачем же это надо тебе, ты никак внятно пояснить не можешь.


 
Суслик ©   (2004-09-08 15:06) [437]


> Акуличев Дмитрий   (08.09.04 15:03) [436]

датасет свой
часть клиенской бд
не очень нагруженной, поэтому без замороенной оптимизации.

ЗЫ. Проше прощения - вчера чуть палец не отрезал. Поэтому сложно набирать без ошибок - а глазами ошибки в тексте я до сих пор вижу плохо.


 
Акуличев Дмитрий   (2004-09-08 15:08) [438]


> Суслик ©   (08.09.04 14:56) [432]
> Поясню, почему меня этот вопрос уже второй год занимает.
> Понимаешь, я чуствую, что здесь есть какая-то глубинная
> (не обозначенная впрочем во всем текущем топике :))) причина.
> Очень хотелось бы услышать, тех кто об этом тоже задумывался.

Причина проста: средств для инициализации/финализации нет, для них были сделаны встроенные процедуры.
Для копирования есть присваивание с приведением типов. Зачем еще вводить в язык лишние сущности?


 
Игорь Шевченко ©   (2004-09-08 15:09) [439]

Суслик ©   (08.09.04 14:56) [432]


> Представь, что реализуешь например свой датасет. Понятно,
> что при серьезной разработке ни вариантами, ни строками
> пользоваться нельзя - надо их эмулировать более оптимально.
> НО для реализации чего-то внесколькократно быстрого чем
> tclientdataset вполно можно пользоваться и AnsiString. Для
> того, чтобы быстро очищать боласти памяти нужно исползовать
> finalize.


Суслик ©   (08.09.04 15:06) [437]

датасет свой

А глупый вопрос - нафига при реализации своего dataset"а использовать такие record"ы ?


 
vuk ©   (2004-09-08 15:09) [440]

to Суслик ©   (08.09.04 14:56) [432]:
>Вот скажи с обозначенной выше точки зрения - чем для меня
>отличается скажем строка и интерфейс с точки зрения управления
>их жизнью?
Объект реализующий интерфейс управляет временем жизни сам на основании счетчика ссылок. Строка - не объект и поэтому ее временем жизни управляет RTL.


 
Суслик ©   (2004-09-08 15:13) [441]


> Акуличев Дмитрий   (08.09.04 15:03) [436]

Ладно, решил пояснить внятно.

Есть свой датасет.
Построен на такой структуре данных:
type
  TData = array[0..оченьмного] of variant;
  PData = ^TData;
Все хранится как
data:PData;

Это по сути последовательно расположенные строки.
Т.е. чтобы взять поле П строки С нужно взять data^[C*КолСтр + П].

Естесно есть всякие операции:
групиировка, сортировка, join и т.д.

В этом случае часто приходится делать move памяти с последующим аккуратным учетом памяти. И часто приходится делать addref областям памяти. Т.к. _addref недокументированная, то приходится делать просто через копирование
destination.data^[...] := source.data^[...].
Легче было бы скопировать через move, затем просто сделать addref скопированной области памяти.

Надеюсь понятно.

Проше не приводить реплики, не относящиеся к сути вопроса.
Ясно, что для серьезных задач (порядка полумиллиона и более строк) такой подход слаб. В этом случае про variant вообще надо запыть - эмулирвоать это иными способами.

Но для поставленных передо мной задач такой подход удовлетворяет как по скорости, так и по объему занимаемой памяти.


 
Акуличев Дмитрий   (2004-09-08 15:15) [442]


> Суслик ©   (08.09.04 15:01) [434]

Ну ёлки-палки.
Указатель же типизированный!

var
 p: PRec;
begin
 New(p);
 p^.s := stringof("0", 10);
 Dispose(p);
end;

"Я тебе умный вешш скажю, толко ты не абыжайся" (ц) Мимино
Учите матчасть!


 
Суслик ©   (2004-09-08 15:15) [443]


> Акуличев Дмитрий   (08.09.04 15:08) [438]
> Причина проста: средств для инициализации/финализации нет,
> для них были сделаны встроенные процедуры.
> Для копирования есть присваивание с приведением типов. Зачем
> еще вводить в язык лишние сущности?

Вот! Очень хороший и граммотный ответ. Наверное в этом и есть дело.


> vuk ©   (08.09.04 15:09) [440]

В данном контексте (в контексте клиента конструкции, т.е. пользователя) имхо эти отличия несущественны.


 
Суслик ©   (2004-09-08 15:17) [444]


> Акуличев Дмитрий   (08.09.04 15:15) [442]

Как ты извините (глагол забыл) со своей матчастью:)))
Это был пример, того как это вообще МОЖНО использоваться, чтобы вопросов по контексту не было, т.е. пояснить о чем я говорю.
---------------------------------------------------------
Все зачмырили. И даже хорошую описанную конструкцию не смей испошльзовать :)))))


 
Суслик ©   (2004-09-08 15:19) [445]


> Акуличев Дмитрий   (08.09.04 15:15) [442]

На самом деле ты скорее всего мне уже дал ответ в 438.
Действительно - наверное не хотели они лишние сущности плодить, вот и не стали описывать addref.

Согласен с тобой, что его всегда можно (не всегда удобно, правда) заменить ":="


 
Акуличев Дмитрий   (2004-09-08 15:24) [446]


> Легче было бы скопировать через move, затем просто сделать
> addref скопированной области памяти.

Не легче.
Подумай, как была бы реализована такая addref и был бы от неё реальный выигрыш.


 
Суслик ©   (2004-09-08 15:25) [447]


> Подумай, как была бы реализована такая addref и был бы от
> неё реальный выигрыш.

Блин (извините) :))

ты еще не понял, что на уже есть :)))

открой system
найди _initialize, пойди 4-5 строчек ниже, увидишь _addref.
Она есть
Она хорошо работает, только параметры приходится передавать в asm.
Я ей непользуюсь, т.к. она НЕдокументированная. Была бы документирвоанная - пользовался бы.


 
Акуличев Дмитрий   (2004-09-08 15:34) [448]

А на матчасть ты зря обижаешься. Оно есть рулез, хотя и не всегда приятный.
Вот только что выкинул в помойку почти готовый RTF парсер, потому что нашёл описание Text Object Model.
Было очень жалко и нецензурно.


 
Акуличев Дмитрий   (2004-09-08 15:38) [449]


> Суслик ©   (08.09.04 15:25) [447]

Да нету там никакого _addref.
Я даже смотреть туда не буду. Нету его там, и быть не может.


 
Суслик ©   (2004-09-08 15:41) [450]


> Акуличев Дмитрий   (08.09.04 15:34) [448]


> А на матчасть ты зря обижаешься. Оно есть рулез, хотя и
> не всегда приятный.

Я не обижаюсь - но ты очень скор на расправу, горячий молдавский (насколько я понимаю) парень :)) И как следствие не всегда объективен :) А раздражает это, просто жуть: люди то все умные, вроде добровольно пришли знаниями делиться, а начинается тако-о-ое ...

Читать я и сам люблю, только я долго это делаю - запомнить факты проще, чем использовать эти факты в творчестве. Поэтому долго перечитываю.

Нашел system._addref?
Я когда-то заставил ее работать - код кто-то дал и сам немного дописал. Т.к. сейчас это не использую, то найти сразу не смог - если найду поделюсь. Точно помню, что она совершенно нормально работала - главное typeInfo передавай.


 
megabyte ©   (2004-09-08 15:43) [451]

Хоть уже много написали, скажу про нашу общагу и универ.
Как то недвано хотел узнать, а кто модер нужной мне конфы про Дельфю, т.к. задал там вопрос, но на негод олго никто не отвечал.

Парниша мне ответил: "А зачем тебе это, Раскаль/Дельфи - это ж мертвый язык..."

И вообще большинство люде не то, что презрительно смотрят, а искренне удивляются, когда говоришь, что программишь на Дельфи. :)

Для все С++ - это просто объект поколнения(ну типа все ОС написаны на С и т.д.), остальное даже не стоит рассматривать.

з.ы. М.б. таких, как я в общаге мало, но я лично никогда не перейду на С++. Конечно, в каждом языке есть свои + и -(ну в с++ получается, только 2 плюса :) ), но мне больше по душе Pascal/Delphi. Хотя и программил-то пока мало.
М.б. и существуют такие задачи, которые удобнее делать на С++, но пока не попадались... :)


 
Суслик ©   (2004-09-08 15:43) [452]


> Акуличев Дмитрий   (08.09.04 15:38) [449]
>
> > Суслик ©   (08.09.04 15:25) [447]
>
> Да нету там никакого _addref.
> Я даже смотреть туда не буду. Нету его там, и быть не может.

Да простит меня хозяин за увеличение объема, но другого пути нет :)))

Модуль system. Дельфи 6.
Кусочек из interface части

procedure _Initialize(p: Pointer; typeInfo: Pointer);
procedure _InitializeArray(p: Pointer; typeInfo: Pointer; elemCount: Cardinal);
procedure _InitializeRecord(p: Pointer; typeInfo: Pointer);
procedure _Finalize(p: Pointer; typeInfo: Pointer);
procedure _FinalizeArray(p: Pointer; typeInfo: Pointer; elemCount: Cardinal);
procedure _FinalizeRecord(P: Pointer; typeInfo: Pointer);
procedure _AddRef;


кусочек из implementation

procedure       _AddRef{ p: Pointer; typeInfo: Pointer};
asm
       MOV     ECX,1
       JMP     _AddRefArray
end;

procedure _AddRefArray{ p: Pointer; typeInfo: Pointer; elemCount: Longint};
asm
       PUSH    EBX
       PUSH    ESI
       PUSH    EDI

       TEST  ECX,ECX
       JZ    @@exit

       MOV     EBX,EAX
       ...
end;


 
Ломброзо ©   (2004-09-08 15:44) [453]

> Акуличев Дмитрий   (08.09.04 15:34) [448]
>А на матчасть ты зря обижаешься. Оно есть рулез,
>хотя и не всегда приятный.
>Вот только что выкинул в помойку почти готовый RTF парсер,
>потому что нашёл описание Text Object Model.

Дайте я вас расцелую!


 
Суслик ©   (2004-09-08 15:45) [454]


> Дайте я вас расцелую!

может лучше сюда?
www.sex-chat.ru :)))

За что, кстати.


 
Акуличев Дмитрий   (2004-09-08 15:49) [455]


> Суслик ©   (08.09.04 15:41) [450]

А, блин. Меня заклинило. Подумал, что внутри _initialize найти _addref.


 
Суслик ©   (2004-09-08 15:52) [456]


> Акуличев Дмитрий   (08.09.04 15:49) [455]

раньше улыбаться начал
сейчас заклин признал :)))))
может и ламерить домой пойдешь? :)))))

ЗЫ. Все исключительная шутка. Говорю об этом зная твою горячность:)
---------------------------
Рад, что понимание достигнуто
Вот посмотри на addref и скажи, почему ее не вынесли в доку.
Я скажу честно, что причин не вижу, ни одной. Может твое знание дельфи поможет в этом разобраться. Выше ты вообще говоря дал ответ, который вполне меня удовелетворяет. Но может еще что накопаешь?


 
Акуличев Дмитрий   (2004-09-08 16:07) [457]


> Суслик ©   (08.09.04 15:52) [456]

Заглянул в system.

Честно, никакого особого сожаления, что эти процедуры не сдлали доступными не испытал. Не дали бы они никакой выгоды, разве что текста меньше писать, вместо цикла -- одну строчку.


 
Акуличев Дмитрий   (2004-09-08 16:09) [458]


> Ломброзо ©   (08.09.04 15:44) [453]

С чегой бы это?


 
Суслик ©   (2004-09-08 16:10) [459]


> Акуличев Дмитрий   (08.09.04 16:07) [457]
Честно, никакого особого сожаления, что эти процедуры не сдлали доступными не испытал

Дмитрий, это эмоции :))
А правда где-то рядом.

Мне всегда странно, когда я вижу схожие вещи в одном и том же куске кода реализованные по-разному.

----------------

Надо будет у самого борланда спросить на форуме.


 
Акуличев Дмитрий   (2004-09-08 16:18) [460]


> Суслик ©   (08.09.04 16:10) [459]

Кстати, а typeinfo ты где брал?


 
Суслик ©   (2004-09-08 16:21) [461]


>
> Кстати, а typeinfo ты где брал?

просматривал cpu строки finiliaze
там вторым параметром.


 
Суслик ©   (2004-09-08 16:23) [462]


> Акуличев Дмитрий   (08.09.04 16:18) [460]

я понимаю, что это может быть неверно.
т.к. от компиляции к компиляции адрес входа в typeinfo может меняться.
Но я и не говорил, что это реально использую. Сделать можно и точка. Как на практике брать адрес typeinfo я не разбирался - наверное можно.


 
jack128 ©   (2004-09-08 16:29) [463]

Суслик ©   (08.09.04 15:43) [452]
Кусочек из interface части

Хе.  А вот в пятерке это все под имплментейшен сидит..
megabyte ©   (08.09.04 15:43) [451]
Для все С++ - это просто объект поколнения(ну типа все ОС написаны на С и т.д.), остальное даже не стоит рассматривать

Логика - супер!!!!! Ос"и написаны на С, а поклоняемся С++
megabyte ©   (08.09.04 15:43) [451]
но я лично никогда не перейду на С++.

Я тоже. А вот на Шарп или Джаву - без проблем..


> Честно, никакого особого сожаления, что эти процедуры
> не сдлали доступными не испытал. Не дали бы они
> никакой выгоды, разве что текста меньше писать, вместо
> цикла -- одну строчку.


type
 TStrArr = array [0..20000] of string;
var
 a, b: TStrArr;
begin
... // тут заполнили массив a. теперь его нужно скопировать в b
// 1 вариант
for i := low(a) to high(a) do
  b[i] := a[i]; // поэлементное копирование + поэлементный AddRef
// 2 вариант
Move(a[0], b[0], (High(a) + 1) * SizeOf(string)); // блочное копирование
for i := low(b) to high(b) do                     // и поэлементный AddRef
  AddRef(@b[i], TypeInfo(string));
end;


Это не преимущество?


 
Суслик ©   (2004-09-08 16:32) [464]


> Это не преимущество?

ну в данном случае, наверное нет - как минимум код длиннее. Кстати сомневаюсь, что второй вариант будет сильно быстрее, чем вариант 1. Думаю будет точно быстрее, если использовать специализированные функции копирвоания памяти (я такие пробовал, автора не помню - работают быстрее move).


 
Акуличев Дмитрий   (2004-09-08 16:40) [465]


> jack128 ©   (08.09.04 16:29) [463]

Не так всё просто. Не все типы можно скопировать просто блочным копированием.


 
Суслик ©   (2004-09-08 16:42) [466]


> Акуличев Дмитрий   (08.09.04 16:40) [465]
> Не так всё просто. Не все типы можно скопировать просто
> блочным копированием.

Димон, ты что-то похоже устал от нашей дискуссии.
Конечно нельзя. Но если бы был addref, то можно было бы.
Вроде об этом и говорим не первый десяток постов:))


 
VMcL ©   (2004-09-08 16:45) [467]

>>all

Я не понял. Шо за дела? Holy War плавно перешел в обсуждение только Delphi. Рубить offtopic!

:O)


 
jack128 ©   (2004-09-08 16:47) [468]

Суслик ©   (08.09.04 16:32) [464]
ну в данном случае, наверное нет - как минимум код длиннее

это не недостаток. Если уж потребоволся доступ к столь низкоуровневым функциям(для оптимизации), то длина и сложность кода уже не так сильно не влияют..


> что второй вариант будет сильно быстрее, чем вариант 1.

я так подумал - он может и медленнее быть..

> Но если бы был addref, то можно было бы.
а что бы это дало? Ты же сам только что показал, что в производительности приемущества нет. Или считаешь, что с другими типами это приемущество появиться? Единственное, что мне приходит на ум - массив упакованных записей.. И то не факт - нужны тесты..


 
Игорь Шевченко ©   (2004-09-08 16:47) [469]

jack128 ©   (08.09.04 16:29) [463]

С моей (лично) точки зрения, это недостаток, так как первый вариант ясен и понятен.


 
jack128 ©   (2004-09-08 16:50) [470]

Игорь Шевченко ©   (08.09.04 16:47) [469]
Насчет ясности кода я все понимаю..


 
Суслик ©   (2004-09-08 16:52) [471]


> jack128 ©   (08.09.04 16:47) [468]

Ты обозначь свою позицияю: ты ЗА или ПРОТИВ наличия addref?
Или сомневаешься.
я как-то не понял пока...


 
Акуличев Дмитрий   (2004-09-08 16:53) [472]


> Суслик ©   (08.09.04 16:42) [466]
>
> Димон, ты что-то похоже устал от нашей дискуссии.
> Конечно нельзя. Но если бы был addref, то можно было бы.

Это всё равно бы получился цикл с поэлементным копированием.

Обрати внимание: код вроде jack128 ©   (08.09.04 16:29) [463] не является потокобезопасным.
А вот поэлементное копирование -- потокобезопасно.

Овчинка выделки не стоит.


 
jack128 ©   (2004-09-08 16:55) [473]

Суслик ©   (08.09.04 16:52) [471]
У меня нет своей позиции. Я не считаю себя компетентным в этом вопросе.


 
Romkin ©   (2004-09-08 16:57) [474]

Замучили флеймить :))
Если функция не документирована - нафиг ее пользовать?
Не документирована - значит, не нужна либо может измениться в будущих версиях. Здесь - вопрос совместимости, не более того :))


 
Суслик ©   (2004-09-08 16:59) [475]


> Акуличев Дмитрий   (08.09.04 16:53) [472]


> Это всё равно бы получился цикл с поэлементным копированием.

ну так е-мое, конечно.
кто спорит.


> Обрати внимание: код вроде jack128 ©   (08.09.04 16:29)
> [463] не является потокобезопасным.
> А вот поэлементное копирование -- потокобезопасно.

вах! Доказать можешь?
Ты уверен, что для строк это будет так
т.е. ты уверен, что тело LStrAsg разработано как потоко безопасное?

ЗЫ. Я не спорю - я хочу понять откуда такая уверенность.


 
Суслик ©   (2004-09-08 17:01) [476]


> Romkin ©   (08.09.04 16:57) [474]

Флеймить?
Мы что-то нарушаем? :))))
Я тебя куда-нить послал или Акуличева?
Не нравится, не смотри.


 
Суслик ©   (2004-09-08 17:05) [477]


> Акуличев Дмитрий   (08.09.04 16:53) [472]

По поводу потокобезопасности копирования строк.
Может ты и прав - вообще все сделано через interloced increment.

Ты до этого сам дошел или явно прочел где-нить?


 
Акуличев Дмитрий   (2004-09-08 17:08) [478]


> вах! Доказать можешь?
> Ты уверен, что для строк это будет так
> т.е. ты уверен, что тело LStrAsg разработано как потоко
> безопасное?

Не был бы уверен -- не говорил бы.
За доказательствами -- в system.pas


 
Акуличев Дмитрий   (2004-09-08 17:11) [479]


> Ты до этого сам дошел или явно прочел где-нить?

И то, и другое.


 
Суслик ©   (2004-09-08 17:12) [480]


> Акуличев Дмитрий   (08.09.04 17:08) [478]

ну в общем-то я уже с тобой выше почти согласился.
почти, т.к.надо еще посмотреть.


 
Суслик ©   (2004-09-08 17:13) [481]


> Акуличев Дмитрий   (08.09.04 17:11) [479]
>
> > Ты до этого сам дошел или явно прочел где-нить?
>
> И то, и другое.

Спасибо, что обратил внимание на этот факт - не знал.

Но скажи где прочел - я не помню, чтобы это факт был задокументирован в штатной доке.

Заранее благодарен за ответ.


 
Акуличев Дмитрий   (2004-09-08 17:22) [482]


> Суслик ©   (08.09.04 17:13) [481]
> Но скажи где прочел - я не помню, чтобы это факт был задокументирован
> в штатной доке.

Прочёл в system.pas ;-)
В доке нет смысла специально это описывать. Имело бы смысл описывать обратную ситуацию: "Внимание! Такая-то сякая-то операция не потокобезопасна!"


 
Суслик ©   (2004-09-08 17:25) [483]


> Акуличев Дмитрий   (08.09.04 17:22) [482]
Имело бы смысл описывать обратную ситуацию: "Внимание! Такая-то сякая-то операция не потокобезопасна!"


ну уж не надо тут нагонять: полно непотокобезопасный операций.

например невинная операция.

var
  I: Int64;
procedure TForm1.Button4Click(Sender: TObject);
begin
  inc(I);
     00452618 8305504C450001   add dword ptr [I],$01
     0045261F 8315544C450000   adc dword ptr [I + $4],$00
end;


Как раз логичнее было бы предположить, что и работа со строками не потокобезопасная.


 
cyborg ©   (2004-09-08 17:28) [484]

Можно и в обратном направлении пойти :), а-то в Паскале нет то, нет сё.
В си нету string-ов таких удобных и нулевой символ нельзя хранить в строке хы хы :)
И нету модулей хе хе
И компиляция идёт долго ха ха
Ошибки запаришься искать гы гы

Вот так, теперь докажи, что не верблюд? ;)


 
Суслик ©   (2004-09-08 17:31) [485]

2cyborg ©   (08.09.04 17:28) [484]

каюсь, давно офтоп развел - про си и дельфи ужа мало кто спорит.
теперь у старших товарищей получаю уроки, которые мне помогают понять, что я такого не знал в дельфи, что си мне казался краше.

:)


 
cyborg ©   (2004-09-08 17:34) [486]


> [485] Суслик ©   (08.09.04 17:31)

Это я ктому, что вечно спорят, что в Дельфи нет того-то и того-то, в то время, когда аналогично чего-то нет в Сишных компиляторах. Уверен что ещё кучу приемуществ можно найти, может я там в чём-то и ошибся :)


 
Nous Mellon ©   (2004-09-08 17:34) [487]


>  [484] cyborg ©   (08.09.04 17:28)

еще чувствителен к регистру бу-бу :)


 
cyborg ©   (2004-09-08 17:36) [488]


> [487] Nous Mellon ©   (08.09.04 17:34)

Что правда чтоли? :)


 
Акуличев Дмитрий   (2004-09-08 17:37) [489]


> Суслик ©   (08.09.04 17:25) [483]

Давай ты не будешь спешить, а будешь думать.
Для начала можешь выписать на бумажку все отличия длинных целых от строк.


 
Суслик ©   (2004-09-08 17:44) [490]


> Акуличев Дмитрий   (08.09.04 17:37) [489]


>
> Давай ты не будешь спешить, а будешь думать.
> Для начала можешь выписать на бумажку все отличия длинных
> целых от строк.

Давай в школу играть не будем? :))) Соберись! :)
Длинные строки имеют достаточно сложную реалзиацию, причем документированную.
Пиши не пиши, но кто тебе обещал, что в функции из system _LStrAsg будет реализована потокобезопасность? Эту же функцию можно точно также написать, и она не будет потокобезопасной.

Т.е. для реализации ее потокобезопасной, нужна воля разработчкика. А воля разработчика обычно бывает задокументированной. Об последнем факти я тебя и спрашивал. Если ответа на вопрос о документации не знаешь, ей богу не надо ничего :)))


 
VMcL ©   (2004-09-08 17:45) [491]

>>Nous Mellon ©  (08.09.04 17:34) [487]

AFAIR, чувствительность к регистру можно отключить в опциях.


 
Акуличев Дмитрий   (2004-09-08 18:09) [492]


> Суслик ©   (08.09.04 17:44) [490]

Не хочешь играть в школу -- думай сам, вся первичная информация у тебя для этого есть. Или удавись.


 
Суслик ©   (2004-09-08 18:36) [493]


> Акуличев Дмитрий   (08.09.04 18:09) [492]
Или удавись.

Ты опять стал хамить.
Очень зря, т.к. ты для учителя как минимум неинформативен. Если тебе доставляет удовольствие обучение, то нужно чуть больше трудится: ну например в качестве демонстрации доброй воли дать хоть раз нормальный ответ на свой наводящий вопрос. Я верю, что такой ответ есть. Но далее моей веры это дело не идет - глазами бы увидеть :))


 
Nous Mellon ©   (2004-09-08 18:54) [494]


> AFAIR, чувствительность к регистру можно отключить в опциях.

Если это так то это наверно одно из самых заблуждений моей жизни...
А в опциях чего, среды? У меня VS.NET никак не найду но тма их столько что мог и просмотреть


 
Ihor Osov'yak ©   (2004-09-08 19:25) [495]

2 [414] vuk ©   (08.09.04 14:19)
> Вмешиваться иной раз все-таки нужно. Но только делать это нужно с полным пониманием происходящего.

Это из розряда исключений, подчеркивающих правило. Впрочем,  раз  применял такую технику.. Естественно, снабдив очень подробными комментариями.. И долго думая перед этим, а стоит ли связываться. Но там иного варианта не было. Правда, за последних три года не было необходимости  повторить эту технику.

2 [413] Суслик ©

> Зачем тогда initilize и finilize документированы?

Это, кажется, Акуличев Дмитрий уже ответил.

> ЗЫ. Еще огромная просьба - сбавить назидательность.
Ок, принято. Но ты немного провоцируешь :-)

>, что был непонят исходный вопрос
нет, был понят. Может аналогия просто не совсем удачная.

зы. А ветка, в общем-то, интересной получилась....
Вот только Romkin мой немного провокационный пост ([312] 07.09.04 16:19))  проигнорировал


 
Акуличев Дмитрий   (2004-09-08 19:33) [496]


> Суслик ©   (08.09.04 18:36) [493]

Проблемы с потоками возникают когда данные находятся в общей памяти, например, глобальные переменные, или переданы по ссылке. Тогда возможен конкурентный доступ на запись.

Теперь рассмотрим случай, когда атомарный тип и строка передаются по значению. С атомарным типом ничего особенного не происходит, создаётся копия и всё. Но это не так для строк. Строка, логически переданная по значению физически является разделяемой копией.
Но в язык строки введены таким образом, чтобы максимально приблизить их поведение к поведению атомарных типов.


 
Суслик ©   (2004-09-08 19:35) [497]


> Ihor Osov"yak ©   (08.09.04 19:25) [495]



> Это, кажется, Акуличев Дмитрий уже ответил.

Он предположил (т.к. про сущестование _addref он не знал), я согласился. Хотель бы узнать не предположения, а результат более долгих размышлений.


> Ок, принято. Но ты немного провоцируешь :-)

Правда? Значит правильно делаю :))), т.к. вы тогда говорите охотней :))


> зы. А ветка, в общем-то, интересной получилась....

Да просто замечательная. К сожалению малоинформативная в основном по причине тупиковых ветвей - кто-то что-то не так понял и понеслась кривая в щавель - доказывай, что все всё не так поняли :)))

Самое полезное, что я для себя узнал, это то, что работа с длинным строками потокобезопасная (надо еще посмотреть). Сильно был этому удивлен, т.к. всегда уж непонятно почему считал иначе. К сожалению, я не смог узнать где это описано в документации.


 
Суслик ©   (2004-09-08 19:41) [498]


> Акуличев Дмитрий   (08.09.04 19:33) [496]


При чем здесь передача в качестве параметров?
Мы говорили про присвоение одного другому? и о том, что LStrAsn написана потокобезопасно и о том, что я от тебя хотел услышать, где ты это прочел в доке (вспомни, ты сам сказал, что это где-то читал).

А что ты скажешь про _LStrSetLength?
Она тоже потоко безопасная?

Скажу честно сразу я так определить не могу - надо посмотреть внимательнее.

Интересно твое мнение?


 
Суслик ©   (2004-09-08 19:58) [499]


> Акуличев Дмитрий   (08.09.04 19:33) [496]

Ну вообще знаешь, старичок, ты наверное прав про потокобезопасность строк: в функции _LStrSetLength работа со счетчиком ссылок также идет как

00404246 F0FF4AF8         lock dec dword ptr [edx-$08]

Ты не разбирался с дин массивами - они тоже потокобезопасные?


 
начинающий ©   (2004-09-08 20:23) [500]

Сказать, что обсуждение не отвечает сабжу - ничего не сказать! Понятно и так, что Дельфи имеет более сильные и более слабые стороны по сравнению с С++. Я, создавая сабж надеялся, что мне помогут здесь понять причину появления слухов о низкой производетельности Дельфи и плохой интеграции с другими технологиями. А вышло, как вышло. Жаль. Модераторы действительно решили дать возможность пофлеймить всем желающим.
Хотя моя делема неразрешена, зато я вижу не зря создал сабж - от этого топика польза, как от алхимии: цели достигнуты небыли, но зато на пути их достижения было сделано множество полезных открытий.


 
Игорь Шевченко ©   (2004-09-08 21:13) [501]

Суслик ©   (08.09.04 19:58) [499]

Ты когда-нибудь книги читать научишься ? Или это настолько тяжкий труд, вроде как мешки ворочать ?


> _LStrSetLength?


> LStrAsn


Открой System.pas и изучай до полного просветления. Когда изучишь - сдай экзамен на форуме.


 
DiamondShark ©   (2004-09-08 21:15) [502]


> Я, создавая сабж надеялся, что мне помогут здесь понять
> причину появления слухов о низкой производетельности Дельфи
> и плохой интеграции с другими технологиями.

А по-моему, на этот вопрос ответили: незнакомство с предметом.


 
DiamondShark ©   (2004-09-08 21:25) [503]


> Суслик ©   (08.09.04 19:41) [498]
>
> При чем здесь передача в качестве параметров?
> Мы говорили про присвоение одного другому?

Передача как параметр по значению -- тоже разновидность присваивания.

Я говорил о том, что работа со строками организована так, чтобы максимально приблизиться к работе с атомарными типами.


и о том, что
> LStrAsn написана потокобезопасно и о том, что я от тебя
> хотел услышать, где ты это прочел в доке (вспомни, ты сам
> сказал, что это где-то читал).

Я сказал где прочитал: в system.pas [482]

Я не разбирался детально со всеми процедурами поддержки автоматически управляемых типов, думаю принцип везде одинаков.

Ты представь, какой бы вой стоял в мире, обнаружись со строками или массивами какие-либо проблемы ;)


 
Cobalt ©   (2004-09-09 11:08) [504]

Ну ладно, холи вар так холи вар!
Суслик, ты, вроде как, знаток у нас С++, объясни:
Если в классе конструктор по-умолчанию (который без параметров), объявить как private, то что же будет при объявлении переменной этого класса(или ньючении памяти под него)?


 
KSergey ©   (2004-09-09 11:14) [505]

> [504] Cobalt ©   (09.09.04 11:08)
> то что же будет при объявлении переменной
> этого класса

Фига, надо полагать? (вот только при компиляции или RunTime...)

Вот все хвалят шаблоны
Да, прикольно
Но понять по сообщениям компилятора где именно ты чего-то не того туды тычешь...


 
wicked ©   (2004-09-09 12:14) [506]

> VMcL [491]

> AFAIR, чувствительность к регистру можно отключить в опциях.

плохой AFAIR - если бы такое было, перестали бы компилироваться около 30 - 40% исходников... просто потому, что кто то отключил опцию...

> KSergey [505]

> Вот все хвалят шаблоны
> Да, прикольно
> Но понять по сообщениям компилятора где именно ты чего-то
> не того туды тычешь...

а шаблоны - это средство "не для всех".... так же, как и написание компонентов в делфи/билдере...
хотя разработчик, выпускающий библиотеку шаблонных классов "в свет", должен указать, какими свойствами должны обладать типы данных, используемые при подстановке в шаблон... как, например, это сделано в документации по stl...


 
VMcL ©   (2004-09-09 12:32) [507]

>>wicked ©  (09.09.04 12:14) [506]

>плохой AFAIR - если бы такое было, перестали бы компилироваться около 30 - 40% исходников... просто потому, что кто то отключил опцию...

Ну при беглом осмотре шестой студии я такой опции не нашел, но то ли в TC 2, то ли в BC++ 3 точно помню - видел.


 
wicked ©   (2004-09-09 12:53) [508]

> VMcL [507]
фполне может быть... но ни в msvc 6/.NET, ни в CBuilder 6, ни в gcc её нету... к остальным средам/компиляторам доступа не имею...


 
Суслик ©   (2004-09-10 10:42) [509]


> Игорь Шевченко ©   (08.09.04 21:13) [501]


> Ты когда-нибудь книги читать научишься ? Или это настолько
> тяжкий труд, вроде как мешки ворочать ?

Какое отношение это высказывание имеет к теме потокобезопасности строк? У?
Ну, навскидочку, где вы прочли про потокобезопасность строк?

Модуль system не счтается: в нем же я нашел _addref, но вы (все) почитали ее недокументированной и недопустимой к использованию. Позвольте мне присоединиться к всеобщему мнению - что недокументировано, то не должно использоваться. Или вы пользуетесь недокументированными функциями? Ну-ну...

Итак вопрос: в какой документации конкретно вы, Игорь, прочти про потокобезопасность строк?

Вопрос ясен? Или надо опять снести несколько учи матчасть, ламери дома и пр? Мне не сложно, но на вопрос, выделенный жирным шрифтом, был бы рад получить более вразумительный ответ, тем более, что вопрос поставлен весьма конкретно.


> > _LStrSetLength?
> > LStrAsn
> Открой System.pas и изучай до полного просветления. Когда
> изучишь - сдай экзамен на форуме.


Так, я не понял - вы вообще читаете посты или как?
Я же сказал, что согласен с фактом потокобезопасности строк, на основе изучения имеено указанных функций. К чему реплика? У?


 
Игорь Шевченко ©   (2004-09-10 10:43) [510]

Суслик ©   (10.09.04 10:42) [509]


> Или вы пользуетесь недокументированными функциями?


Я пользуюсь головой. Чего и вам желаю.

LMD


 
Суслик ©   (2004-09-10 10:53) [511]


> Игорь Шевченко ©   (10.09.04 10:43) [510]


> Я пользуюсь головой. Чего и вам желаю.

Не научтите? А?

Детский сад, извините...

Поясняю вопрос.

Есть определенная ТЕКУЩАЯ реализация, какой-нибудь операции. Вы спец в асме, и вы прсоматривая cpu выяснили что-то. Вы видите, что эта операция недокументированная.

Вот например, недавно у меня с АП был разговор насчет того, что запись StrRec (служебная информация о длинных строках) выглядит так
 StrRec = packed record
   refCnt: Longint;
   length: Longint;
 end;

а не так
StrRec = packed record
   Some: LongInt; // неиспользуемые 4 байта.
   refCnt: Longint;
   length: Longint;
 end;

Анатолий говорил, что запись занимает 12 байт - я, что 8. Мы оба оказались правы - в д6 - 8 байт, в д5 (если не ошибаюсь) - 12. При этом эта особенность недокументирована в принципе. Если кто-то на нее бы заложился, то в будущей версии дельфи у него были бы проблемы.

Поэтому, не знаю как другие, но я, даже если знаю, не пользуюсь тем, что не указано в документации (желательно официальной). Неужто нелогично?

Также и со строками. Предположим, что они реализованы но НЕДОКУМЕНТИРОВАНЫ потокобезопасно для личных нужно самого борланда. В таком случае у него есть полное право сменить реализацию. Если же сей факт указан в доке, то сделать он этого не может.

Вот и жду, что кто-нибудь скажет про место в документации, где бы это было сказано.


> LMD

Сильно я тебя достал, чем только? :))


 
GRAND25 ©   (2004-09-10 10:53) [512]

У Игоря весьма неординарная голова. Какие там могут быть недокументированные функции? И рядом не валялись!


 
Суслик ©   (2004-09-10 10:55) [513]


> GRAND25 ©   (10.09.04 10:53) [512]


> У Игоря весьма неординарная голова. Какие там могут быть
> недокументированные функции? И рядом не валялись!

Никто не спорит о его голове.

Вопрос то не в том, чтобы знать, а в том, чтобы использовать.

Я тоже знаю некоторые недокументированные фукнции. Но что мешает им перестать работать с следующей версии дельфи?

Или следующей версии не будет? :))


 
GRAND25 ©   (2004-09-10 10:58) [514]


> Или следующей версии не будет? :))


Если и будет, то за поддержку этих недокументированных функций в том же виде и с тем же набором параметров никто ответственности не понесет.


 
GRAND25 ©   (2004-09-10 11:01) [515]


> > LMD
>
> Сильно я тебя достал, чем только? :))


Ничем не достал. Просто все окружающие - ламеры по сравнению с такой неординарностью, как Игорь, по определению...


 
Суслик ©   (2004-09-10 11:03) [516]


> GRAND25 ©   (10.09.04 10:58) [514]


> Если и будет, то за поддержку этих недокументированных функций
> в том же виде и с тем же набором параметров никто ответственности
> не понесет.

я про это и говорю.

Непользование недокументированными возможностями мое глубокое убеждение. Если оно ламерское убеждение - мне пофигу (честно).


 
GRAND25 ©   (2004-09-10 11:06) [517]


> Если оно ламерское убеждение - мне пофигу (честно).


Любое убеждение, отличное от убеждений Игоря Шевченко - ламерское. Но и я с этим как-то живу...


 
имя   (2004-09-10 11:58) [518]

Удалено модератором


 
Суслик ©   (2004-09-10 12:02) [519]


>  [518] Профи   (10.09.04 11:58)


> И все у тебя будет хорошо.

У меня и так все хорошо
------------------------
Оправдай, кстати, свой ник - где в доке сказано про потокобезопасность строк?


 
pasha_golub ©   (2004-09-10 12:34) [520]

Суслик ©   (10.09.04 12:02) [519]
А может это само собой размуеющееся? Ну, вроде как строки базовый тип всегда был. Щас конечно реализация посложней, но все-таки.

Я вот никогда не задумывался, потокобезопасны ли строки. Всегда считал, что да.


 
DiamondShark ©   (2004-09-10 12:41) [521]


> где в доке сказано про потокобезопасность строк?

Нигде. Это требуется для приближения поведения строк к поведению атомарных типов.


 
Суслик ©   (2004-09-10 12:45) [522]


>  [521] DiamondShark ©   (10.09.04 12:41)


> Нигде. Это требуется для приближения поведения строк к поведению
> атомарных типов.

Спасибо за ответ.
Четкий и понятный.
Всегда бы так.
------------
Похоже динамические массивы тоже потокобезопасные :)))
------------
Век живи - век учись.


 
panov ©   (2004-09-10 12:52) [523]

>Суслик ©   (10.09.04 12:02) [519]

где в доке сказано про потокобезопасность строк?

А с чего бы им быть потокобезопасными?


 
Суслик ©   (2004-09-10 12:55) [524]


>  [523] panov ©   (10.09.04 12:52)


> А с чего бы им быть потокобезопасными?

Об этом сказал Акуличев.
Судя по всему строки действитель потокобезопасные.
По крайней мере об этом говорит анализ _LStrAsg и _LStrClr.

Я, как я честно сказал этого не знал. Вот и мучает вопрос - где и как я мог это пропустить. Пока в доке не нашел.

Тот же Акуличев говорит, что факт потокобезопасности строк нигде не указан.


 
panov ©   (2004-09-10 12:56) [525]

>Суслик ©   (10.09.04 12:55) [524]

В Delphi работа со строками не потокобезопасна.


 
Суслик ©   (2004-09-10 12:59) [526]


> panov ©   (10.09.04 12:56) [525]
В Delphi работа со строками не потокобезопасна.

Разве?
Во блин, кому верить? :))
Здесь два варианта, либо вы заблуждаетесь, либо нет.

В первом варианте меня убеждает анализ кода некоторых функций вида _LStrXXX. В пользу второго - я тоже так всегда считал.

Так где правда?


 
DiamondShark ©   (2004-09-10 13:01) [527]


> В Delphi работа со строками не потокобезопасна.

И сразу пример.


 
Cobalt ©   (2004-09-10 13:05) [528]

Суслик, может ты всё-таки ответишь, пока они там решают - потокобезопасны строки или нет, на мой вопрос? Cobalt © [504]


 
DiamondShark ©   (2004-09-10 13:07) [529]


> Так где правда?

Как известно, в вине.

var
 S: string; // глобальная;

function Thread1(Param: pointer): integer;
begin
 S := "aaa";
end;

function Thread2(Param: pointer): integer;
begin
 S := "bbb";
end;

Результат неопределён (сравни с поведением того же integer).

В этом смысле они не безопасны.

Но вне зависимости от того, что будет присвоено глобальной переменной, все счётчики ссылок, все операции с памятью пройдут корректно.

В этом смысле я подразумевал безопасность.


 
Суслик ©   (2004-09-10 13:08) [530]


> Cobalt ©   (10.09.04 13:05) [528]

я не спец с сях. Там я ламер и ламерю обычно дома - просто компилю разные кусочки.

за синтаксис прошу прощения - плохо помню

class a {
  private a;
};

{
  a*i;
  i = new a; // это в vsc++ даст ошибку компиляции
}


что будет со стековыми переменным т.е.

{
  a i;
}


не знаю не проверял.


 
pasha_golub ©   (2004-09-10 13:08) [531]

DiamondShark ©   (10.09.04 13:07) [529]
Согласен с утверждением.


 
Ihor Osov'yak ©   (2004-09-10 13:31) [532]

>Любое убеждение, отличное от убеждений Игоря Шевченко - ламерское. Но и я с этим как-то живу...

Хм... Иронию ироните?
Кстати, лично мне не припоминается, чтобы в вопросах, имеющих отношение к программингу, Шевченко давал ошибочную информацию и придерживался своей точки зрения, после того, когда конкретно и аргументировано укажут на неточности (было раз или два по мелочам или ньюансам)...
В "хвилосовско-нравственно-политических" вопросах все очень субьективно, посему этой темы не затрагиваем.


 
panov ©   (2004-09-10 13:52) [533]

Пример? Пожалуйста.


type
 TMyTestThread1=class(TThread)
 protected
   procedure Execute;override;
 end;

 TMyTestThread2=class(TThread)
 protected
   procedure Execute;override;
 end;

s1,s2: String;

impementation

procedure TMyTestThread1.Execute;
begin
 FreeOnTerminate := True;
 try
   s2 := s1;
   move(s1[1],s2[1],Length(s1));
 except
   MessageBox(0,"Error","Error",MB_OK);
 end
end;

procedure TMyTestThread2.Execute;
begin
 FreeOnTerminate := True;
 Sleep(1);
 s2 := "";
end;

procedure TForm1.Button2Click(Sender: TObject);
var
 t1: TMyTestThread1;
 t2: TMyTestThread2;
begin
 s1 := StringOfChar("a",100000000);
 s2 := StringOfChar("b",100000000);

 t1 := TMyTestThread1.Create(False);
 t2 := TMyTestThread2.Create(False);


 
Ihor Osov'yak ©   (2004-09-10 14:01) [534]

2 [533] panov ©   (10.09.04 13:52)

э, батенька, дык Вы шарлатанством занимаетесь.. По вашей логике ничто не есть потокобезопасным....


 
panov ©   (2004-09-10 14:05) [535]

>Ihor Osov"yak ©   (10.09.04 14:01) [534]

э, батенька, дык Вы шарлатанством занимаетесь.. По вашей логике ничто не есть потокобезопасным....


Тогда определимся, что считать потокобезопасным кодом?

В контексте предыдущих обсуждений нужно немного видоизменить формулировку вопроса - "Что такое потокобезопасный код?"


 
GRAND25 ©   (2004-09-10 14:07) [536]


> Хм... Иронию ироните?


Ыгы! Ыроним! :)


> В "хвилосовско-нравственно-политических" вопросах все очень
> субьективно, посему этой темы не затрагиваем.


Конечно субъективно! Субъективно в соответствии с мнением И.Шевченко :)


 
panov ©   (2004-09-10 14:07) [537]

Работа со строками, как и с другими объектами, не может быть потокобезопасной, так как всегда возможны коллизии при одновременном использовании.


 
Суслик ©   (2004-09-10 14:11) [538]


> Тогда определимся, что считать потокобезопасным кодом?

Давайте рассмотрим вопрос потокобезопасности пока только для строк.

Я считаю, что потокобезопасной работой со строками нужно считать такую работу, когда факт доступа к строке из нескольких потоков не может повлиять на скрытую от программиста обработку строк - выделение памяти, подсчет ссылок и т.д.

Естесно, что такая потокобезопасность возможна только в случае использования штатных фукнций дельфи. Т.е. никаким move здесь не место!

Ясный перец, что в этом случае программист берет на себя всю ответсвенность за происходящее.


 
DiamondShark ©   (2004-09-10 14:13) [539]


> panov ©   (10.09.04 13:52) [533]

Грязный хак.


 
Суслик ©   (2004-09-10 14:15) [540]


>  [537] panov ©   (10.09.04 14:07)
> Работа со строками, как и с другими объектами, не может
> быть потокобезопасной, так как всегда возможны коллизии
> при одновременном использовании.

Вы, безсуловно, правы.
Но я бы назвал указанные вами колизии логическими ошибками.

Т.к. я еще с детского сада знаю, как устроены строки (выделение памяти, подсчет ссылок), то мне всегда казалось что само собой разумеещеся, что такая в общем-то непростая реализация строк не потокобезопасна - т.е. при доступе из разных потоков могут быть ошибки вплоть до AV и пр.

Вот факт невозможности получения ошибкок чисто технического характера для меня оказался новостью.

А вот логические ошибки - они везде возможны, даже в атомарных типах.


 
Ihor Osov'yak ©   (2004-09-10 14:18) [541]

2 [535] panov ©   (10.09.04 14:05)

Вам уже ответили - 538, 540


 
DiamondShark ©   (2004-09-10 14:28) [542]


> panov ©   (10.09.04 14:07) [537]

Коллизии коллизиям рознь.
Есть коллизии типа "потеря значения", а есть коллизии управления внутренним представлением объектов.

При работе со строками (стандартными средствами, разумеется) возможны только первые.


 
Суслик ©   (2004-09-10 14:31) [543]

Эх!
Здорово, хоть понимание достигнуто.


>  [542] DiamondShark ©   (10.09.04 14:28)

Ты мне все же скажи - дин. массивы тоже потокобезопасные? Смотрел их?

У меня слабое знание asm, поэтому достоверно понять самому сложно. Вернее понять можно, не знаю верить себе или нет :)


 
DiamondShark ©   (2004-09-10 14:44) [544]


> Суслик ©   (10.09.04 14:31) [543]

Я детально не разбирался.
На первый беглый взгляд -- вроде бы очень на строки похоже.


 
pasha_golub ©   (2004-09-10 15:54) [545]

По моему, ИМХУ, строки = дин. массивы


 
Суслик ©   (2004-09-10 15:56) [546]


>  [545] pasha_golub ©   (10.09.04 15:54)
> По моему, ИМХУ, строки = дин. массивы

Это в каком смысле? Реализация у них разная, да и семантика разная.


 
jack128 ©   (2004-09-10 16:10) [547]

Суслик ©   (10.09.04 15:56) [546]
Реализация у них разная

с чего это вдруг?? Длина, счетчик ссылок - все как у строк..


 
Суслик ©   (2004-09-10 16:15) [548]


>  [547] jack128 ©   (10.09.04 16:10)

Строки копируются, у массиво копируется только ссылка. У строк тоже копируется ссылка, но при первом изменеии одной из строк происходит создание копии. Т.о. на оригинал не влияет. У массивов, если не ошибаюсь, копирование происходит только при изменении размеров массива. Если же менять элемент массива, то изменение в копии скажутся и на оригинале.


 
pasha_golub ©   (2004-09-10 16:16) [549]

Над строками больше автоматической работы проводится компилером, как по мне. А так схожесть есть.


 
jack128 ©   (2004-09-10 16:36) [550]

Суслик ©   (10.09.04 16:15) [548]
но при первом изменеии одной из строк происходит создание копии.


Угу. Но у массивов создания копии не происходит.. Их поведение ещё проще строки..


 
Суслик ©   (2004-09-10 16:47) [551]


> Угу. Но у массивов создания копии не происходит.. Их поведение
> ещё проще строки..

Если я не ошибаюсь не совсем так.
Копирование массива происходит при изменении размера.

Я точно не помню. Если интересно, сам посмотри.


 
Megabyte-Ceercop ©   (2004-09-10 17:12) [552]

Я недели две назад перешёл на си++.
Ничего, работать хоть и муторно, но можно.
Главная награда в конце - скорость работы приложения.
Я правда это относительно игр, и DirectX.

А вот оконные стандартные вещи, где скорость не главное - лучше на Старом, добром Delphi ваять. :))

ИМХО.


 
имя   (2004-09-10 18:01) [553]

Удалено модератором


 
имя   (2004-09-10 18:12) [554]

Удалено модератором


 
имя   (2004-09-10 18:17) [555]

Удалено модератором


 
VMcL ©   (2004-09-10 18:22) [556]

>>Megabyte-Ceercop ©  (10.09.04 17:12) [552]

C++ к скорости никакого отношения не имеет. Это заслуга конкретного компилятора.

>Главная награда в конце - скорость работы приложения.

После таких заявлений было бы неплохо увидеть факты, а проще говоря, числа.


 
имя   (2004-09-10 18:29) [557]

Удалено модератором


 
GRAND25 ©   (2004-09-10 18:40) [558]


> Ничего, работать хоть и муторно, но можно.


Стоит ли так себя мучить?


 
GrayFace ©   (2004-09-12 16:56) [559]

Игорь Шевченко ©   (07.09.04 22:04) [336]
Вот мне интересно - как ты себе предстваляешь одновременно наличие переменной Result и оператора return (допустим, он появился в Delphi).

А в чем проблема? Так, как я это написал в макросе. А можно так: Return - выход с возвращением Result, Return 3 или Return(3) - выход с возвращением 3.

>> Там это заменяет множественное наследование
> Где это - там ?

В Java.

>> В общем, вам тоже в школу надо.
> Не потрудится ли достопоченный дон объяснить, почему
> именно мне надо в школу ? :)

Учить, учить и еще раз учиь :) Цитата, кстати, неверная - у меня в конце смайлик был.

<font color=red><strike>имя</strike></font>   (08.09.04 7:57) [343]
<font color=red><strike>имя</strike></font>   (08.09.04 10:41) [345]
Зачем удалили?

0d08h   (08.09.04 11:11) [352]
А между кем и кем была Holy War пару десятков лет назад?

Danilka ©   (08.09.04 11:39) [371]
Обычные задачи - Delphi; там, где нужна хитрая структура объектов - C++, как кто-то сказал. (Это не есть мое мнение)

Суслик ©   (08.09.04 14:46) [427]
Была бы недокументированная - не в жизь не пользовался бы - никогда так не делаю.

И сообщениями, начинающимися с CM (CM_MouseLeave и т.д.) тоже не пользуешься? Они тоже недокументированы.

Суслик ©   (08.09.04 16:10) [459]
Дмитрий, это эмоции :))
А правда где-то рядом.

Да. В следующем предложении. :) Между прочим, move - не чем не лучше обычного копирования в цикле по 4 байта. А на малых объемах хуже во много раз.
jack128 ©   (08.09.04 16:29) [463]
>Суслик ©   (08.09.04 15:43) [452]
>Кусочек из interface части
> Хе.  А вот в пятерке это все под имплментейшен сидит..

В семерке - тоже, кажется. Т.к. компиллятор ее не видит.

jack128 ©   (08.09.04 16:29) [463]
Вариант 1 лучше во всем, включая скорость. Смысл в move есть только когда копируюется много структур с размером, не кратным 4.

> AFAIR, чувствительность к регистру можно отключить в опциях.
А че такое AFAIR?


 
cyborg ©   (2004-09-12 17:10) [560]

Так тут идёт сравнения языка С++ с компилятором Дельфи? Неправильно это. Лечше сравнивать С++  с объект паскалем, тогда могу пример привести из Фрипаскаля. Результат функции при выходе можно назначить как:

Function:=X;
Exit;
или
Result:=X;
Exit;
или
Exit(X);


 
GrayFace ©   (2004-09-12 18:15) [561]

Игорь Шевченко ©   (08.09.04 21:13) [501]
Суслик ©   (08.09.04 19:58) [499]
Ты когда-нибудь книги читать научишься ? Или это настолько тяжкий труд, вроде как мешки ворочать ?

Книг очень много и они денег стоят.

DiamondShark ©   (08.09.04 21:25) [503]
Я сказал где прочитал: в system.pas [482]

Дак оказывайтся ты и Акуличев Дмитрий - одно лицо! Это многое объясняет.

wicked ©   (09.09.04 12:14) [506]
плохой AFAIR - если бы такое было, перестали бы компилироваться около 30 - 40% исходников... просто потому, что кто то отключил опцию...

Да прросто эта опция должна быть директивой компиллятора, влияющей только на конкретный юнит.

Суслик ©   (10.09.04 10:53) [511]
Детский сад, извините...

Пора заканчивать детский сад - в школу пора, как я уже говорил. :) Шутка.

Ihor Osov"yak ©   (10.09.04 14:18) [541]
2 [535] panov ©   (10.09.04 14:05)

Вам уже ответили - 538, 540


По вашему 538<535? :)

Megabyte-Ceercop ©   (10.09.04 17:12) [552]
Главная награда в конце - скорость работы приложения.


Заметна разница в скорости???!!!

cyborg ©   (12.09.04 17:10) [560]
Exit(X);
В Delphi не действует. А FreePascal, ИМХО, можно использовать только на олимпиадах.


 
Igorek ©   (2004-09-12 20:32) [562]


> Ihor Osov"yak ©   (10.09.04 14:01) [534]
> 2 [533] panov ©   (10.09.04 13:52)
> По вашей логике ничто не есть потокобезопасным....

Совершенно верно. Потоков нету ни в С++ ни в Дельфи.



Страницы: 1 2 3 4 5 6 7 8 9 
10 11 12 13 14 15 вся ветка

Форум: "Потрепаться";
Текущий архив: 2004.10.03;
Скачать: [xml.tar.bz2];

Наверх





Память: 2.26 MB
Время: 0.056 c
14-1094798237
PVOzerski
2004-09-10 10:37
2004.10.03
Есть ли sudo и альтернативные системы ввода пароля для NT?


1-1095488674
aglar
2004-09-18 10:24
2004.10.03
Thread?


14-1095295675
Soft
2004-09-16 04:47
2004.10.03
Там они пообедали фруктами, посмотрели кино и застрелились.


3-1094201922
Klerk
2004-09-03 12:58
2004.10.03
Insert c датой


14-1095141285
Мазут Береговой
2004-09-14 09:54
2004.10.03
Ну, вот всё встало на свои места... :-)





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский