Operator overloading

← →
REA (2007-03-30 10:08) [0]

Дождались...
http://dn.codegear.com/article/34324

← →
Чапаев © (2007-03-30 10:16) [1]

Да, есть версии Делфи и выше седьмой. Для тебя это новость?

← →
REA (2007-03-30 10:21) [2]

Ну ладно там Class Helpers или final methods, но чтобы операторы перегружать...
А с D7 сравнивают по двум причинам: она стабильна и мало что сделано по сравнению с D2006

← →
Чапаев © (2007-03-30 10:28) [3]

> Ну ладно там Class Helpers или final methods, но чтобы операторы
> перегружать...
Ну это, сопсна, уже года полтора как не новость, если не больше. Так что удивлённые глаза с тарелку не к месту...

← →
Jan (2007-03-30 10:51) [4]

чего-то я не вьеду - Since Delphi 7 начиная с 7-го или после 7-го?

← →
wicked © (2007-03-30 10:52) [5]

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

← →
Чапаев © (2007-03-30 10:54) [6]

> [4] Jan (30.03.07 10:51)
"С тех пор, как была Д7"...

← →
Чапаев © (2007-03-30 10:55) [7]

> вот если для записей можно перегружать операции....
Ну. Можно. А что?

← →
Jan (2007-03-30 10:56) [8]

а... они чуть ниже написали...
Abstract: See many of the major new language features in Delphi released after the Delphi 7 version
И чего это не написать в заголовке?

← →
Суслик © (2007-03-30 10:57) [9]

В win32 перегрузка операторов работает только для записей.
Для классов - нет.

Почитал. Все правильно - ничего не забыли упомянуть :)

PS abstract для классов в BDS2006 не работает :) Компилиться, но не фунциклирует.

← →
wicked © (2007-03-30 10:59) [10]

> Чапаев © (30.03.07 10:55) [7]

> > вот если для записей можно перегружать операции....
> Ну. Можно. А что?

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

← →
_Аноним (2007-03-30 11:00) [11]

Я что-то не врубился.
Имеется в виду наверно таки "2007" а не "7"?
Потому что ну нету сейчас (у меня 2006) перегрузки операторов, нету.
Я даже не поленился, попробовал этот код откомпилить (ну мало ли чего)...

← →
wicked © (2007-03-30 11:01) [12]

> Суслик © (30.03.07 10:57) [9]

> В win32 перегрузка операторов работает только для записей.
> Для классов - нет.

значит все правильно :)

← →
Суслик © (2007-03-30 11:05) [13]

>>Потому что ну нету сейчас (у меня 2006) перегрузки операторов, нету.
для классов ее и нет
есть для записей.

← →
Суслик © (2007-03-30 11:07) [14]

перегрузка есть для классов, но в delphi for net

← →
_Аноним (2007-03-30 11:09) [15]

> Суслик ©

> есть для записей.

И в BDS2006 есть для записей?? 8-0

← →
Суслик © (2007-03-30 11:09) [16]

да

← →
Суслик © (2007-03-30 11:10) [17]

> [15] _Аноним (30.03.07 11:09)

если у тебя bds2006 стоит, то перейди по урле
ms-help://borland.bds4/bds4ref/html/OperatorOverloads.htm

← →
_Аноним (2007-03-30 11:14) [18]

> Суслик ©

да уж...
Век живи век учись, называется.. :-)

← →
Суслик © (2007-03-30 11:14) [19]

> да уж...
> Век живи век учись, называется.. :-)

все проще: поставил новую дельфи, прочти object pascal reference.
чтения на несколько часов.

← →
Ketmar © (2007-03-30 11:29) [20]

а я давно говорил: расстрелять. без права на обжалование. с ужасом жду появления препроцессора a-la C. пойду лучше на C++ писать -- всё равно нормальному языку Delphi -- гайки. %-(

← →
Игорь Шевченко © (2007-03-30 11:30) [21]

> а я давно говорил: расстрелять

За метлой сходил ?

← →
Ketmar © (2007-03-30 11:33) [22]

и за пивом тоже.

Игорь, ну вот поясни мне: на какой половой орган нужны:
хэлперы
перегрузка функций
перегрузка операторов

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

← →
Игорь Шевченко © (2007-03-30 11:42) [23]

Ketmar © (30.03.07 11:33) [22]

> всё, что оно делает -- усложняет код

Не всегда. Если ты помнишь, то против helper"ов я довольно активно выступал. За одним редким исключением - для связи TObject с System.Object кроме helper"ов трудно что-либо придумать.

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

Так что пулю побереги :)

← →
Ketmar © (2007-03-30 11:49) [24]

> Игорь Шевченко © (30.03.07 11:42) [23]
> Собственно, введение всех новых возможностей языка не принуждает
> к их безоговорочному использованию, поэтому если что-то
> не нравится до отторжения - проще не использовать, чем расстреливать
> авторов языка.
так если бы только мной ограничивалось. ведь мы же используем сторониий код, нес па? а с появлением новых фич их будут внедрять в этот код. хотя бы для того, чтобы пиарить ("мы уже стираем тайдом!"). если фичи нет -- её и не "переиспользуют". %-)

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

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

← →
Суслик © (2007-03-30 12:02) [25]

> [24] Ketmar © (30.03.07 11:49)

> кодежыр пошёл по пути маркетинга. вместо пути багофиксов
> и развития. собственно, именно это меня бесит.

есть такое, но не совсем.

баги они все-таки фиксят, причем весьма активно.
более 70% процентов отслеживаемых мною багов в д2007 пофиксено.

в основном баги были как раз по новым фичам. очень много было по записям с методами. много поправили.

← →
Игорь Шевченко © (2007-03-30 12:02) [26]

Ketmar © (30.03.07 11:49) [24]

> это да. но добавление новых фич упрощает процесс написания
> нечитабельного бреда

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

← →
Игорь Шевченко © (2007-03-30 12:08) [27]

Суслик © (30.03.07 12:02) [25]

> баги они все-таки фиксят, причем весьма активно.

Давай не надо. Я не работал с D8, но судя по отзывам это было как тухлое яйцо - обращаться бережно и с осторожностью, не дай Аллах задеть.
Появился D2005, который на простых нетребовательных проектах вел себя довольно сносно, но на более сложных начинал вести себя непредсказуемым образом. Ну то есть, совсем непредсказуемым.
Через год появился D2006, который, по моему скромному мнению, представлял из себя относительно 2005 то же, что второй сервис-пак для Windows XP, с одной только разницей - второй сервис-пак для XP раздавался всем желующим, а 2006 - за денежку.

Так в D2006 тоже, как выяснилось, багов немеряно, у меня отсылка репортов при падениях среды уже автоматически происходит. И что предлагается ? D2007 как сервис-пак за денежку ?

← →
Ketmar © (2007-03-30 12:09) [28]

> Игорь Шевченко © (30.03.07 12:02) [26]
я в курсе, что бред можно написать даже имея в распоряжении всего три оператора. но имея 33 его (бред) написать проще. вон Кнут вообще писал на псевдоасме -- и ничего. всё понятно.

← →
Суслик © (2007-03-30 12:25) [29]

> [27] Игорь Шевченко © (30.03.07 12:08)
> Суслик © (30.03.07 12:02) [25]
> > баги они все-таки фиксят, причем весьма активно.
> Давай не надо.

Ты что оспариваешь? То что они баги фиксят? Вообще о чем речь - в чем я не прав? :)
Баги фиксят, продают за бабки. Это факты.

Разговор же шел о фиксе багов. Это они делают. Про другое я и не говорил.

← →
Ketmar © (2007-03-30 12:30) [30]

угу. фиксят. через 5-7 лет. офигеть фиксы. D2-D7, баг с case был жив. а багрепорт был написан ещё во времена D3. про баги с оптимайзером я лучше вообще промолчу...

← →
Игорь Шевченко © (2007-03-30 12:31) [31]

Суслик © (30.03.07 12:25) [29]

Как баги фиксятся - ты знаешь не хуже меня. Меня, как пользователя Delphi не интересует, какое количество багов они пофиксили в D2006 относительно D2005, меня интересует НОРМАЛЬНАЯ СТАБИЛЬНАЯ РАБОТА средства разработки. А с увеличением номера версии я ожидаю новых возможностей, желательно безглючных, а не фиксенных багов. Баги фиксятся update pack"ами и hotfix"ами

← →
Суслик © (2007-03-30 12:35) [32]

> НОРМАЛЬНАЯ СТАБИЛЬНАЯ РАБОТА средства разработки.

я в части стабильности БДС2006 весьма доволен.
Убрал все insight"ы (code, error)
Убрал структуру модуля (когда дерево классов в тек. модуле выводится).

Падать перестала в принципе.

Не дело это, конечно, но добиться устойчивой работы можно.

← →
Ketmar © (2007-03-30 12:47) [33]

угу. "убрать то-то и то-то, тогда заработает". обалдеть политика.

и, кстати: ГДЕ, блин, опция "component palette a-la D7"?! сторонние решения не предлагать. зачем было ломать отличную IDE в угоду MSVS?

хорошо хоть, что форму можно оторвать и сделать как в D7. хоть это дали...

← →
Суслик © (2007-03-30 12:50) [34]

> [33] Ketmar © (30.03.07 12:47)

упертый ты - говорить с тобой не интересно :)

← →
Игорь Шевченко © (2007-03-30 12:57) [35]

Суслик © (30.03.07 12:35) [32]

Без code insight работать в принципе неудобно. С таких же успехом можно набирать код в текстовом редакторе и компилировать компилятором командной строки.

← →
Ketmar © (2007-03-30 13:02) [36]

> Суслик © (30.03.07 12:50) [34]
> упертый ты - говорить с тобой не интересно :)
тогда пивом пои. %-)

← →
Суслик © (2007-03-30 13:09) [37]

> [35] Игорь Шевченко © (30.03.07 12:57)
> Суслик © (30.03.07 12:35) [32]
>
> Без code insight работать в принципе неудобно. С таких же
> успехом можно набирать код в текстовом редакторе и компилировать
> компилятором командной строки.

я имел в виду автоматический code insight - когда набрал идентификатор и точку и автоматически открывается окно. Я это убрал - жму ctrl+space.

← →
Ketmar © (2007-03-30 13:14) [38]

> Суслик © (30.03.07 13:09) [37]
> я имел в виду автоматический code insight - когда набрал
> идентификатор и точку и автоматически открывается окно.
> Я это убрал - жму ctrl+space.
да-да-да. автоматическая коробка передач -- маст дай. всё надо делать ручками!

← →
clickmaker © (2007-03-30 13:16) [39]

> автоматическая коробка передач -- маст дай. всё надо делать
> ручками!

кстати, иногда "автоматически открывается окно" правда раздражает. потому как склероз еще не до такой степени развился )

← →
Ketmar © (2007-03-30 13:22) [40]

ключевое слово -- "иногда". %-)

← →
euru © (2007-03-30 14:57) [41]

class sealed
В Delphi есть атрибут метода abstract. Теперь этот атрибут распространили до уровня класса (class abstract). Добавили новый атрибут метода final. Почему тогда по аналогии с class abstract нельзя было вместо class sealed использовать class final?

class type
В примере тип объявлен внутри раздела private. Если следовать концепциям ООП, этот раздел доступен только внутри класса и невидим извне. Однако в примере имеется обращение к полю приватного раздела. Нет ли в этом противоречия?

final methods
Исходя из текста (и здравого смысла) атрибутом final могут помечаться только виртуальные методы. Но объявлять метод виртуальным и тут же приписывать к нему атрибут final, как мне кажется, бессмысленно. Поэтому все final будут писаться вместе с override. Почему бы тогда вместо override; final; просто не писать final?

static class methods
А какие у таких методов особые преимущества по сравнению с обычными class methods, чтобы добавлять в язык такое понятие?

Ну, про недоделанные class helpers и records with methods я уже говорил ранее. :)

← →
antonn © (2007-03-30 15:06) [42]

вы только не пинайте, что такое "перезагрузка записей"? :)

← →
властелин колхоза (2007-03-30 15:10) [43]

> В примере тип объявлен внутри раздела private. Если следовать
> концепциям ООП, этот раздел доступен только внутри класса
> и невидим извне. Однако в примере имеется обращение к полю
> приватного раздела.
У Делфи к приватным полям может обращаться всяк, кто расположен в том же модуле. ;-)

← →
Чапаев © (2007-03-30 15:11) [44]

Ой... Надо ж... На рабочем компе древний ник остался.

← →
Суслик © (2007-03-30 15:15) [45]

> [41] euru © (30.03.07 14:57)
> class sealed
> В Delphi есть атрибут метода abstract. Теперь этот атрибут
> распространили до уровня класса (class abstract). Добавили
> новый атрибут метода final. Почему тогда по аналогии с class
> abstract нельзя было вместо class sealed использовать class
> final?

Потому, что так. Какая разница? Синтаксис такой.

> class type
> В примере тип объявлен внутри раздела private. Если следовать
> концепциям ООП, этот раздел доступен только внутри класса
> и невидим извне. Однако в примере имеется обращение к полю
> приватного раздела. Нет ли в этом противоречия?

Private в дельфи всегда такой был - в рамках модуля можно обращаться.
для того, чтобы было нельзя есть strict private

> final methods
> Исходя из текста (и здравого смысла) атрибутом final могут
> помечаться только виртуальные методы. Но объявлять метод
> виртуальным и тут же приписывать к нему атрибут final, как
> мне кажется, бессмысленно. Поэтому все final будут писаться
> вместе с override. Почему бы тогда вместо override; final;
> просто не писать final?

Синтаксис такой.

> static class methods
> А какие у таких методов особые преимущества по сравнению
> с обычными class methods, чтобы добавлять в язык такое понятие?

Не передается ссылка на класс. Т.е. это типа процедуры.

← →
euru © (2007-03-30 15:16) [46]

> властелин колхоза (30.03.07 15:10) [43]
> У Делфи к приватным полям может обращаться всяк, кто расположен
> в том же модуле. ;-)
Из контекста примера не следует, что обращение идёт из того же модуля, где было сделано объявление.

← →
Чапаев © (2007-03-30 15:20) [47]

> [46] euru © (30.03.07 15:16)
Не вели казнить, вели слово молвить... Я даже не знаю, о каком примере речь идёт... %-)

← →
euru © (2007-03-30 15:28) [48]

> Чапаев © (30.03.07 15:20) [47]

Подсказка №1:
Вся необходимая информация есть в этой ветке.

Подсказка №2:
Ищите перед Чапаев © (30.03.07 10:16) [1]

Подсказка №3:
http://dn.codegear.com/article/34324

:)

← →
euru © (2007-03-30 15:41) [49]

> Суслик © (30.03.07 15:15) [45]
> Какая разница? Синтаксис такой.
Потому что происходит засорение языка действительно лишними и/или двусмысленными понятиями.

← →
Суслик © (2007-03-30 17:18) [50]

> [49] euru © (30.03.07 15:41)

синтаксис штука такая - его не выбирают, к нему привыкают. имхо.
намного хуже, когда идет засорение семантики.

← →
Gero © (2007-03-30 17:25) [51]

О, теперь и на делфи можно будет писать по-настоящему уродский код.

← →
Loginov Dmitry © (2007-03-30 19:47) [52]

Пипец! Так опошлить хороший язык! Докатились... :(

← →
celades © (2007-03-30 21:09) [53]

> О, теперь и на делфи можно будет писать по-настоящему уродский
> код.

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

← →
TUser © (2007-03-30 21:26) [54]

> Игорь Шевченко
> Ketmar

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

← →
Суслик © (2007-03-30 23:36) [55]

> TUser © (30.03.07 21:26) [54]

+1

← →
XProger © (2007-03-31 07:09) [56]

http://www.everfall.com/paste/id.php?e9u2qyntctbw не знаю как вам, но перегрузка операторов сделала мой код значительно светлее и симпатишнее...
Speed := VAdd(Speed, VMult(Acc, Time)) Speed := Speed + Acc * Time;
Какой по-вашему код является супер правильным и читабельным? )

← →
euru © (2007-04-01 12:55) [57]

> Суслик © (30.03.07 17:18) [50]
Оно понятно, что теперь вам придётся привыкать к такому синтаксису. Но всё-таки у разработчиков должно же было хватить ума хоть немного подумать, как наиболее гармонично ввести в Delphi новые сущности, прежде чем бездумно брать кальки с других языков.

Да и непоследовательны они. Понятия final, sealed, static один в один спёрли, а при перегрузке операторов эти самые операторы заменили их синонимами. Зачем? Неужели operator +(a, b: MyType): MyType будет непонятен программисту Delphi? При этом их заменили даже не названиями операторов, а названиями действий, которые по смыслу не всегда могут совпадать с действиями, совершаемыми над тем или иным типом. И кстати, если я буду перегружать, например, оператор Subtract, смогу ли я объявить в том же классе поле или метод с таким же именем?

Про static class methods я так и не понял. Ну, не передаётся ссылка на класс. Ну и что? Какие это даёт преимущества по сравнению с методами, в которые она передаётся? А если всё-таки это так важно, неужели по контексту тела этого метода нельзя определить, используется в нём эта ссылка или нет? И если не используется, то генерировать метод без передачи этой ссылки.

← →
Суслик © (2007-04-02 10:27) [58]

> [57] euru © (01.04.07 12:55)

синтаксис - дело привычки.
главное, чтобы работало верно.

про static class method.
во-первых способ вызова разный:
1. если non-static class method, то reference to metaclass is passed as parameter.
2. если static class method, то провсто вызывается соответствующий метод - никаких параметров не передается.

разница понятно:
1. non-static class method совместим с method of object.
2. static class method совместим с обычным процедурным типом.
(стоит заметить, что это у них не до конца реализовано, т.е. есть ошибки, но хотят реализовать они это именно так, как написано выше).

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

т.е. static class method - это совершенно классически для других языков статический метод, у которого раньше не было аналога в дельфи.

← →
Игорь Шевченко © (2007-04-02 10:28) [59]

TUser © (30.03.07 21:26) [54]

А ты только со своим кодом сталкиваешься ? Завидую...
Надо же, столько счастья в одни руки :)

← →
Суслик © (2007-04-02 10:37) [60]

> [59] Игорь Шевченко © (02.04.07 10:28)

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

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

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

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

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

не будешь же ты утверждать, что малое количество фичей есть достаточное ИЛИ необходиме условие понятного кода?

да эти вещи вообще не связаны никак.

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

← →
oxffff © (2007-04-02 10:39) [61]

> Игорь Шевченко © (30.03.07 11:42) [23]
> Ketmar © (30.03.07 11:33) [22]
>
>
> > всё, что оно делает -- усложняет код
>
>
> Не всегда. Если ты помнишь, то против helper"ов я довольно
> активно выступал. За одним редким исключением - для связи
> TObject с System.Object кроме helper"ов трудно что-либо
> придумать.

Для новых конструкций языка таких так
for in, необходимо в "старые классы" добавить поддержку итераторов.

Что лучше всего поможет нам.

Догадайтесь

← →
Суслик © (2007-04-02 10:40) [62]

> for in, необходимо в "старые классы" добавить поддержку
> итераторов.

в многие стандартные классы уже добавлено

← →
oxffff © (2007-04-02 10:48) [63]

> Суслик © (02.04.07 10:40) [62]
>
> > for in, необходимо в "старые классы" добавить поддержку
>
> > итераторов.
>
> в многие стандартные классы уже добавлено

Это известно.
Просто хотелось еще раз для Игоря Шевченко показать на примере смысл
этого

Class helpers provide a way to extend a class, but they should not be viewed as a design tool to be used when developing new code. They should be used solely for their intended purpose, which is
language and platform RTL binding

Вот еще

http://17slon.com/blogs/gabr/2007/03/fun-with-enumerators-part-5-class.html

← →
oxffff © (2007-04-02 10:57) [64]

to Игорь Шевченко
из

http://17slon.com/blogs/gabr/2007/03/fun-with-enumerators-part-5-class.html

Admit it, class helpers are great. They can also be great source of problems. Class helpers were introduced mainly for internal CodeGear use and they have one big limitation - at any given moment, there can be at most one helper active for a given class.

You can define and associate multiple class helpers with a single class type. However, only zero or one class helper applies in any specific location in source code. The class helper defined in the nearest scope will apply. Class helper scope is determined in the normal Delphi fashion (i.e. right to left in the unit"s uses clause). [excerpt from Delphi help]

Но вот здесь я соглашусь с мнением Игоря Шевченко

IOW, if Delphi already includes class helper for a class and you write another, you"ll loose the Delphi-provided functionality. (You can inherit from the Delphi class helper though - read more in Delphi help.)

Use class helpers with care!

Но написать шустрый, но непонятный код, можно и на Delphi7.

Как?

asm
..................
end;

← →
Игорь Шевченко © (2007-04-02 11:02) [65]

Суслик © (02.04.07 10:37) [60]

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

Не буду спорить. Я уже приводил этот аргумент, спорить с самим собой бессмысленно.

> а то, что смотреть это кому-то будет неудобно, то меня это
> вообще мало волнует

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

← →
oxffff © (2007-04-02 11:15) [66]

> К сожалению, не только тебя. Это-то и плохо, так как с твоим
> кодом я не сталкиваюсь, а вот с кодом других авторов, которых
> так же мало волнует, что кому-то будет неудобно, сталкиваться
> приходится.

А ваш код, Игорь Шевченко, будет хорошо восприниматься другими?
Уверен что у многих в вашему коду будут замечания.

Вы говорите о единой стандартизации?
Вы ее соблюдаете?

← →
Игорь Шевченко © (2007-04-02 11:22) [67]

oxffff © (02.04.07 11:15) [66]

До сих пор жалоб не слышал

← →
Empleado © (2007-04-02 11:28) [68]

> REA (30.03.07 10:08)
> Дождались...
> http://dn.codegear.com/article/34324

Спасибо за новости.
Будем вникать. Много чего произошло после D7, не знал.
До вчерашней недели пользовался только им. В пятницу поставил честно купленный D2007 for W32. Посмотрим...

← →
oxffff © (2007-04-02 11:31) [69]

> Игорь Шевченко © (02.04.07 11:22) [67]
> oxffff © (02.04.07 11:15) [66]
>
> До сих пор жалоб не слышал

Вы наверно один и на ассемблере(хотя бы x86).
Конструкции простые.
Нет там Class helpers.

:)

На правду похоже вот это

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

← →
oxffff © (2007-04-02 11:33) [70]

Да, и даже профессионал профессионалу скажет я бы сделал по другому.

← →
Игорь Шевченко © (2007-04-02 11:44) [71]

oxffff © (02.04.07 11:31) [69]

> Вы наверно один и на ассемблере(хотя бы x86).
> Конструкции простые.

Переведи

← →
oxffff © (2007-04-02 11:50) [72]

> Игорь Шевченко © (02.04.07 11:44) [71]
> oxffff © (02.04.07 11:31) [69]
>
>
> > Вы наверно один и на ассемблере(хотя бы x86).
> > Конструкции простые.
>
>
> Переведи

Вы наверно пишите на ассемблере и пишите один.
Mov,lea ,jz,jzn,jmp,stos... -Конструкции простые

>До сих пор жалоб не слышал

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

← →
oxffff © (2007-04-02 11:51) [73]

jzn= jnz

← →
Суслик © (2007-04-02 11:54) [74]

> [67] Игорь Шевченко © (02.04.07 11:22)
> oxffff © (02.04.07 11:15) [66]
>
> До сих пор жалоб не слышал

неправда Ж)

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

было 1.5-2 года назад.

ты сказал... да ничего не сказал - типа нефих с тобой спорить :)

← →
Игорь Шевченко © (2007-04-02 12:11) [75]

> Вы наверно пишите на ассемблере и пишите один.

Да, именно так и происходит.

Суслик © (02.04.07 11:54) [74]

> было 1.5-2 года назад.
>
> ты сказал... да ничего не сказал - типа нефих с тобой спорить
>

Вот это память - обзавидоваться можно.

← →
Суслик © (2007-04-02 12:19) [76]

> Вот это память - обзавидоваться можно.

да фиговая память :)
просто вспомнилось - само както :)
наверное сильно запала несправедливость.

----
я еще по теме добавлю.
мое мнение - любой чужой код С ПЕРВОГО ВЗГЛЯДА всегда потемки. просто хороший чужой код приятней, полезней и легче изучать

← →
oxffff © (2007-04-02 12:22) [77]

> просто хороший чужой код приятней, полезней и легче изучать

Хороший код = свой код (психология). Факт.

Хороший чужой код = код написанный другим под твою диктовку.

:)

← →
oxffff © (2007-04-02 12:24) [78]

Уважаемые вы что все на UML сидите?

← →
Игорь Шевченко © (2007-04-02 12:25) [79]

oxffff © (02.04.07 12:22) [77]

Вот есть исходные тексты VCL - все понятно. Хотя код не свой.

← →
Суслик © (2007-04-02 12:29) [80]

> [79] Игорь Шевченко © (02.04.07 12:25)
> oxffff © (02.04.07 12:22) [77]
> Вот есть исходные тексты VCL - все понятно. Хотя код не
> свой.

Понятно, потому что изучал ты его.

Возьми grids.pas. Если тебе там все понятно - ты гений. Честное слово, не шучу. Мне там многое понятно - процентов 70, но я и изучал его в сумме часов 100.

← →
oxffff © (2007-04-02 12:34) [81]

> Вот есть исходные тексты VCL - все понятно. Хотя код не
> свой.

Сколько прошло времени от начало знакомства с VCL до понимания.
Я имею ввиду об устройстве.
Думаю не 1 неделя и не один месяц.

Вот на чем спотыкаются сразу начинающие.
А эти дебри недокументированны.

-MakeObjectInstance
-FreeObjectInstance

← →
oxffff © (2007-04-02 12:40) [82]

function StdWndProc(Window: HWND; Message, WParam: Longint;
LParam: Longint): Longint; stdcall; assembler;

А это сущность обработки сообщений.
И это мы еще не дошли до dynamic методов обработчков конкретных сообщений.

← →
Игорь Шевченко © (2007-04-02 13:36) [83]

oxffff © (02.04.07 12:34) [81]

> Сколько прошло времени от начало знакомства с VCL до понимания.
>
> Я имею ввиду об устройстве.

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

← →
oxffff © (2007-04-02 13:52) [84]

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

Прошли годы. До "реального" осознования работы VCL.

>И потому как код ясный и понятный.

Прошли опять же годы до вылизивания.
Я уверен у них есть места, где нужно произвести рефакторинг.
Но в угоду совместимости, его не сделают.

Вот простой пример

procedure TForm1.Button1Click(Sender: TObject);
var a:TComboBox;
begin
a:=TComboBox.Create(nil);
try
showmessage(inttostr(a.Items.count));
finally
a.free;
end;
end;

Вы что мне скажите?
-Так устороена VCL. Все запросы через через посылку сообщений.

-А я вам скажу. Это логично?

Поэтому приходится довольствоваться тем, что имеем.

А то что ясен код или не ясен.
Отвечу разобраться можно.
Только реально иногда это очень надоедает.

Я честно говоря не

← →
Игорь Шевченко © (2007-04-02 15:00) [85]

oxffff © (02.04.07 13:52) [84]

> Вот простой пример
>
> procedure TForm1.Button1Click(Sender: TObject);
> var a:TComboBox;
> begin
> a:=TComboBox.Create(nil);
> try
> showmessage(inttostr(a.Items.count));
> finally
> a.free;
> end;
> end;

Можно и штаны через голову надевать, только неудобно.

К чему ты этот кусок кода привел?

> Можно и штаны через голову надевать, только неудобно.
>
> К чему ты этот кусок кода привел?

Так вы запустите.

> Суслик © (02.04.07 10:27) [58]
> про static class method.
Я так понял, что static ввели, чтобы:
1. обеспечить совместимость с .Net (с классами, написанными на других языках);
2. обеспечить обратную совместимость с предыдущими версиями Delphi.

А почему тогда отказались от такого варианта:
1. Выкинуть из обычных классовых методов параметр Self. Это обеспечило бы совместимость с другими языками в .Net.
2. Объявить в свойство Self (ссылка на метакласс), доступное во всех классах, но только в классовых методах. Это обеспечит обратную совместимость с предыдущими версиями.

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

Немного уклонюсь от темы, но задам вопрос касательно нововведений.
Покажите для чего и как можно использовать class abstract?

oxffff © (02.04.07 15:41) [86]
Так вы запустите.

а чего его запускать то? И так понятно, что с вероятностью 50/50 либо ноль выведет, либо "window has not parent" или как там эта ошибка звучит . Тут семи пядей во лбу не нужно, что это понять.

> jack128 © (04.04.07 11:05) [89]
> oxffff © (02.04.07 15:41) [86]
> Так вы запустите.
>
> а чего его запускать то? И так понятно, что с вероятностью
> 50/50 либо ноль выведет, либо "window has not parent" или
> как там эта ошибка звучит . Тут семи пядей во лбу не нужно,
> что это понять.

"window has not parent" - это нормально и логично для подобного запроса?

> Вы что мне скажите?
> -Так устороена VCL. Все запросы через
> через посылку сообщений.

Так устроена Windows!

oxffff © (04.04.07 11:12) [90]

> "window has not parent" - это нормально и логично для подобного
> запроса?

Это нормально и логично. Если кто-то создает контролы с nil в качестве владельца, то он должен быть готов к таким сообщениям. Если кто-то ComboBox использует вместо TStringList, по проблемы логики - это сугубо его проблемы.

oxffff, tesseract, скажу даже больше, так устроена вся объектная модель Delphi, любой класс в состоянии обрабатывать message директивы наложенные на его методы (TObject.Dispatch)

> Так устроена Windows!

Нет так устроена VCL.
Если делаешь wrapper вокруг ComboBox, то делать нужно нормально.

проблема в подходе VCL, создание-пересоздание окон на лету.

>Если кто-то ComboBox использует вместо TStringList, по проблемы логики - >это сугубо его проблемы.

Проблема была в том (так нужно мне), что при разрушения Tcombobox он должен передать свое состояние другому объекту. Но если к этому моменту произошел вызов DestroyWindowHandle, то сделать это уже невозможно.
Проблема здесь в самом подходе VCL, а именно в создании и разрушении окон on time.
Решение безусловно найдено.
Но собственно если опираетесь на windows combobox, то создайте и не разрушайте его. А Wnd обработчик пусть в зависимости о состояния игнорирует сообщения. Либо динамически меняется на другой например пустой.

> oxffff, tesseract, скажу даже больше, так устроена вся объектная
> модель Delphi, любой класс в состоянии обрабатывать message
> директивы наложенные на его методы (TObject.Dispatch)

Я вам еще больше скажу. Это здесь вообзще непричем.
На dynamic методах никуда не уедешь, если в WndProc не вызвать Dispatch

To Игорь Шевченко

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

procedure TForm1.Button1Click(Sender: TObject);
var a:TComboBox;
begin
a:=TComboBox.Create(self);
try
a.Parent:=self;
a.Items.Add("A1");
a.Items.Add("A2");
a.Parent:=nil;
a.parent:=self;
showmessage(inttostr(a.Items.count));
finally
a.free;
end;
end;

Что код выдаст 2. А почему?

Смотрим

procedure TCustomComboBox.DestroyWnd;
begin
if FItems.Count > 0 then
begin
FSaveIndex := ItemIndex;
FSaveItems := TStringList.Create;
FSaveItems.Assign(FItems);
end;
inherited DestroyWnd;
end;

Аналогично в procedure TCustomComboBox.CreateWnd;

Был бы еще один способ только вот незадача FSaveItems: TStringList в private секции.

Подход VCL в oxffff © (04.04.07 12:32) [96]
указывает на заплатки VCL, которые не были учтены в при дизайне TControl и в особенности TWincontrol.

> Я сильно извиняюсь, а зачем такой ерундой страдать ?

Для демонстрации того, что при разрушении окна, происходит сохранение
списка в FSaveItems. При пересоздании окна его заполнение из FSaveItems.

Все это указывает на вынужденные заплатки.

oxffff © (04.04.07 12:46) [99]

Если ты посмотришь, при каких условиях вызывается DestroyWindowHandle, это наведет тебя на путь к истине

> Если ты посмотришь, при каких условиях вызывается DestroyWindowHandle,
> это наведет тебя на путь к истине

Вы говорите загадками.

Вызывается DestroyWindowHandle из деструктора, и из DestroyWnd;
Учтите, что в моем случае еще до вызова деструктора, окно уже разрушено
(Twincontrol.Parent:=nil).

Вы посмотрите, что происходит при Twincontrol.Parent:=nil,
окно гарантированно разрушается.

oxffff © (04.04.07 13:56) [101]

Ну правильно. При смене стиля окна с дочернего на недочернее или наоборот, окно необходимо создать заново - так Windows устроена.
Чему ты удивляешься ?

To Игорь Шевченко

При разрушении родителя или при явном вызове destroy.
В деструкторе еще можно обратиться к "окну" поскольку оно еще не разрушено.
Но если вызвать явно parent:=nil, то окно гарантированно разрушится.
Почему это происходит.

Есть редактор в нем есть средства. У каждого средства свои настройки.
В зависимости от выбранного средства появляется свой frame настроек.
Поэтому постоянно у этого фрейма идет вызов

при активации ToolOptionsFrame.parent:=ToolOptionsWindow
при деактивации ToolOptionsFrame.parent:=nil;

По завершении нужно обратиться к средствам и считать настройки.
Но окно разрушено.

Путь к истине.

Вы его видите?

> Чему ты удивляешься ?

Я соственно не удивляюсь.
Просто считаю, что появление ошибки "Сontrol has no parent window" не должно вообще происходить. Ведь по логике причем здесь компонент и отсутствие окна.

В случае с Tcombobox им можно было поступить. Как вариант

При отсутствии окна a.Items работает FSaveItems,
при наличие использует TComboBoxStrings.

oxffff © (04.04.07 14:05) [103]

> Но если вызвать явно parent:=nil, то окно гарантированно
> разрушится.
> Почему это происходит.

потому что так устроена Windows

> Путь к истине.
>
> Вы его видите?

Путь к истине лежит в изучении матчасти.

> Просто считаю, что появление ошибки "Сontrol has no parent
> window" не должно вообще происходить. Ведь по логике причем
> здесь компонент и отсутствие окна.

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

← →
REA (2007-04-04 14:33) [106]

Тут не все так очевидно. В приснопамятной MFC создавая Page Control можно было добраться до свойств Control-ов только текущей открытой страницы ибо windows убивал Handle всего что не видно. В Delphi это маскируется и можно работать с чем угодно не особенно заботясь есть у него Handle или будет попозже.

> потому что так устроена Windows

Фразу "Почему это происходит" относилась к тому что было написано после нее. Это был не вопрос.
Далее я пояснил почему это происходит.

> Путь к истине лежит в изучении матчасти.

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

> По логике ты создаешь Control класса COMBOBOX. Если твоя
> логика этот факт игнорирует, то смени логику.

Вы считаете что структура классов VCL и схема их взаимодействия оптимальна?

Если я хочу узнать у контрола столько в нем элементов. То сделать он должен это в любое время своей жизни. И не ссылаться на, на то что сделать это он не может.

Поэтому если вылезают ошибки Сontrol has no parent Window.
То это как раз проблемы тех, кто писал его.
Поскольку наличие или отсутствие окна ни как не должна быть связана с функциональностью контрола. И даже wrapper контрола.

Еще раз повторю VCL нужен рефакторинг.

Несмотря на это
http://www.stevetrefethen.com/blog/VCLAndRTLEnhancementsSinceDelphi7D7.aspx

детские болезни VCL перерастают в хронические

oxffff © (04.04.07 14:43) [107]

> Если я хочу узнать у контрола столько в нем элементов. То
> сделать он должен это в любое время своей жизни. И не ссылаться
> на, на то что сделать это он не может.

Бред.

> Еще раз повторю VCL нужен рефакторинг.

"You say you want a revolution
Well, you know
We all want to change the world
You tell me that it"s evolution
Well, you know
We all want to change the world
But when you talk about destruction
Don"t you know that you can count me out
Don"t you know it"s gonna be all right
all right, all right"

(c) Beatles

> Бред.

Где?

> > Еще раз повторю VCL нужен рефакторинг.
>
>
> "You say you want a revolution
> Well, you know
> We all want to change the world
> You tell me that it"s evolution
> Well, you know
> We all want to change the world
> But when you talk about destruction
> Don"t you know that you can count me out
> Don"t you know it"s gonna be all right
> all right, all right"
>
> (c) Beatles

Я к счастью на PRODIGY воспитан.

oxffff © (04.04.07 14:53) [109]

> Где?

Очевидно в процитированном высказывании: "Если я хочу узнать у контрола столько в нем элементов. То сделать он должен это в любое время своей жизни. И не ссылаться на, на то что сделать это он не может."

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

> Я к счастью на PRODIGY воспитан.

Так какая разница - язык английский, как в help"е

TO Игорь Шевченко

Следуя вашей логики.
Нет окна, нет контрола.

Только вот, что не срастается по вашей логике

Почему тогда Tcontrol.left:=100 при parent=nil не вызывает Сontrol has no parent Window.

И уже я спешу вашу логику назвать бредом.

>
> Так какая разница - язык английский, как в help"е

Текст я понял.

Поймите же вы наконец.
У меня нет вопросов по устройству VCL.

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

> oxffff © (04.04.07 15:04) [113]

> контрол должен сказать сколько в нем строк

> Потому что понятие контрола не основано на понятии окна

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

> Конкретный контрол ничего тебе не должен.

Это то понятно.

То есть ваш лозунг Да здраствует "Сontrol has no parent Window".

> Почему тогда Tcontrol.left:=100 при parent=nil не вызывает
> Сontrol has no parent Window.
>
> И уже я спешу вашу логику назвать бредом.

Здесь я имею ввиду, что согласно логике это тоже должно приводить к исключению при отсутствии окна.
Почему это не происходит понятно (для тех кто цепляется к словам).

oxffff © (04.04.07 14:59) [111]

> Следуя вашей логики.
> Нет окна, нет контрола.
>
> Только вот, что не срастается по вашей логике
>
> Почему тогда Tcontrol.left:=100 при parent=nil не вызывает
> Сontrol has no parent Window.

Не все контролы являются TControl, часть из них является TWinControl. А в их поведении имеется существенная разница.

> Не все контролы являются TControl, часть из них является
> TWinControl. А в их поведении имеется существенная разница.
>

Тогда если судить "по вашему"
Twincontrol.SetBounds должен генерировать исключение при HandleNotAllocated.

Но он это не делает.
Здесь логика одна, а вот здесь другая.

У меня нет вопросов ни к вам, ни к VCL.

Так устроено. И менять никто уже ничего не будет.

> при активации ToolOptionsFrame.parent:=ToolOptionsWindow
> при деактивации ToolOptionsFrame.parent:=nil;
>
> По завершении нужно обратиться к средствам и считать настройки.
>
> Но окно разрушено.
>
> Путь к истине.
>
> Вы его видите?

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

ЗЫ: Попробуйте, уважаемый оратор, в рантайме сменить выравнивание текста с EditBox-е. Это так, простейший пример.

> Twincontrol.SetBounds должен генерировать исключение при
> HandleNotAllocated.
>
> Но он это не делает.

И правильно делает. Если окно не создано - то никто не мешает задать значение свойства, чтобы оно потом было взято при реальном создании окна. Вот захотели вы в конструкторе задать левую границу - а окно не создано. Что теперь, вешаться на обработчик OnCreate оконного контрола. запоминать что там было назначено, а после отработки возвращать? Вообще, судя по вашим речам - мне кажется что у вас маленький опыт программирования, а вы тут о рефакторинге. У меня самого лет 7, но я еще очень давно понял, насколько это геморройно сделать процесс создания окон оптимальным и своевременным. И часто алгоритм программ приходилось подстраивать, а не тупо требовать "дайте мне окно". И вообще, ВЦЛ устроена так, что программист должен заботиться о том, создано окно или нет, и когда оно пересоздается.

Поэтому тут два выхода - либо пользовать то, что есть, и так, как надо, либо совсем не пользовать.

> SPeller © (04.04.07 17:37) [119]
>
> > при активации ToolOptionsFrame.parent:=ToolOptionsWindow
> > при деактивации ToolOptionsFrame.parent:=nil;
> >
> > По завершении нужно обратиться к средствам и считать настройки.
>
> >
> > Но окно разрушено.
> >
> > Путь к истине.
> >
> > Вы его видите?
>
> Никогда не храните данные в контролах. Когда-то давно услышал
> эту простую истину. Вам она тоже подойдет. Специфика виндов
> такая. А если уж совсем не нравится ВЦЛ - перепишите. Откомпилите
> системные модули по-новой и вперед пользоваться тем что
> устраивает.
>
> ЗЫ: Попробуйте, уважаемый оратор, в рантайме сменить выравнивание
> текста с EditBox-е. Это так, простейший пример.
>
>
> > Twincontrol.SetBounds должен генерировать исключение при
>
> > HandleNotAllocated.
> >
> > Но он это не делает.
>
> И правильно делает. Если окно не создано - то никто не мешает
> задать значение свойства, чтобы оно потом было взято при
> реальном создании окна. Вот захотели вы в конструкторе задать
> левую границу - а окно не создано. Что теперь, вешаться
> на обработчик OnCreate оконного контрола. запоминать что
> там было назначено, а после отработки возвращать? Вообще,
> судя по вашим речам - мне кажется что у вас маленький опыт
> программирования, а вы тут о рефакторинге. У меня самого
> лет 7, но я еще очень давно понял, насколько это геморройно
> сделать процесс создания окон оптимальным и своевременным.
> И часто алгоритм программ приходилось подстраивать, а не
> тупо требовать "дайте мне окно". И вообще, ВЦЛ устроена
> так, что программист должен заботиться о том, создано окно
> или нет, и когда оно пересоздается.
>
> Поэтому тут два выхода - либо пользовать то, что есть, и
> так, как надо, либо совсем не пользовать.

Малыш не встревай во взрослый разговор.

>Что теперь, вешаться на обработчик OnCreate оконного контрола. >запоминать что там было назначено, а после отработки возвращать?

Ты хоть понял что сказал?

> Что теперь, вешаться на обработчик OnCreate оконного контрола.
> запоминать что там было назначено, а после отработки возвращать?
>

Cобытие OnCreate нет у Tcontrol и TWincontrol.

Так что несмотря на твои семь программирования.
Ничему ты так и не научился.
Даю тебе еще семь лет на обучение. А после посмотрю взять тебя или нет к себе на работу.

Operator overloading Найти похожие ветки