Нужен третейский судья :)

← →
DevilDevil © (2013-04-23 17:42) [120]

> Ega23 © (23.04.13 17:30) [119]

когда ты компилируешь pas в dcu в x86 и x64 - тебя почему-то не смущает, что на выходе получаются 2 совершенно разных dcu
когда ты компилируешь под разными версиями Delphi - ты почему то тоже не удивляешься, что на выходе получаются разные dcu
более того, разная комбинация опций компилятора делают разные dcu - и это тоже никого не парит

Но добавление одного пользовательского дифайна вводит в ступор весь форум мастеров дельфи
Мне кажется это грустно

← →
_oxffff (2013-04-23 17:45) [121]

> дифайн - это режим работы

Вот так и рождаются слухи.

← →
Ega23 © (2013-04-23 17:45) [122]

Vox populi vox Dei.
Селяви.

← →
DevilDevil © (2013-04-23 17:59) [123]

> _oxffff (23.04.13 17:45) [121]

> Вот так и рождаются слухи.

какие ваши доказательства ?

← →
картман © (2013-04-23 19:30) [124]

ну, так чего там - с тупого или острого?

← →
oxffff © (2013-04-23 19:43) [125]

> DevilDevil © (23.04.13 17:59) [123]
> > _oxffff (23.04.13 17:45) [121]
>
> > Вот так и рождаются слухи.
>
> какие ваши доказательства ?

Ну по фильму я тебе по идее должен сломать ногу и высыпать материал.

> дифайн - это режим работы

Режим работы определяется внутренней логикой зависящей от внутреннего состояния.

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

← →
DevilDevil © (2013-04-23 20:33) [126]

> oxffff © (23.04.13 19:43) [125]

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

← →
Ega23 © (2013-04-23 22:30) [127]

> прости, но я не уловил логику
> ты уверен, что она действительно есть ?

Наверное, ты ещё слишком молод и не знаешь, что такое KOKANHYM

← →
Владислав © (2013-04-23 22:52) [128]

Если бы небыло этой инициализации класса внутри самого юнита - то и спора никакого небыло бы :)
Обманул в изначальном вопросе. :)

← →
Аббат Пиккола (2013-04-23 22:59) [129]

Несколько предложений.
1. Вообще выбросить нафиг эту переменную. Обойтись без нее вообще. Если кому-то нужна, пусть у себя объявит. Класс есть. ИМХО, этого за глаза достаточно.
2. Если уж обязательно нужна глобальная переменная в одном месте, то разговоры о классе TFoo2 требуют какого-то механизма, который определял бы класс этой глобальной переменной. Наверно можноо создать еще одну глобальную переменную, в котороую будет записываться ссылка на нужный класс. А функция Foo пусть создает экземпляр указанного класса как-нибудь. Я это не умею, но думаю, что это возможно.

Хотя мне это все не нравится. Если возможны какие-то наследники от TFoo, то что произойдет, если кто-то вздумает иметь 2 разных класса-наследника? Инициализироваться-то будет в любом случае экземпляр какого-то конкретного класса, так как объект - одиночка. Другой класс окажется обиженным в такой ситуации. Точно так же обиженным, как TFoo2 в случае функции Foo.

Я бы послал вообще эту глобальную переменную. Если двое спорят о том, как это реализовать и каждый подход имеет свои недостатки, может лучше вообще от нее избавиться и дело с концом? Т.е. я за мой вариант 1. Лучший способ решить проблему - ликвидировать саму проблему. Кому нужно пусть У СЕБЯ объявляет глобальную переменную и делает с ней, что хочет.

← →
sniknik © (2013-04-24 08:19) [130]

> Лучший способ решить проблему - ликвидировать саму проблему.
а она ликвидируется?
стоят двое на остановке спорят
- по моему, туда где мы вчера бухали, не помню куда, нужно ехать на 5-ом автобусе, конечная остановка...
- а по моему, тоже не помню, на 7-м, тоже конечная...
...
- ликвидируйте проблему, езжайте на такси!
- ???

> Кому нужно пусть У СЕБЯ объявляет глобальную переменную и делает с ней, что хочет.
зачем останавливаться на полпути? кому нужно тот пусть пишет свой класс/объект и делает с ним что хочет.
только вот это уже не будет общий модуль, с общей логикой, а будет куча частных реализаций. при изначальном - нужен синглетон. или не нужен... если хочется второй экземпляр.
у автора в общем то спор, а не вопрос из-за не знания как сделать. думаю он и сам способен придумать кучу извращенных вариантов. но чем это кого то убедит?

← →
oxffff © (2013-04-24 09:08) [131]

> sniknik © (24.04.13 08:19) [130]

:)
+10.

← →
Ega23 © (2013-04-24 09:23) [132]

> зачем останавливаться на полпути? кому нужно тот пусть пишет
> свой класс/объект и делает с ним что хочет.

Во! Точняк!

← →
DevilDevil © (2013-04-24 09:35) [133]

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

← →
Юрий Зотов © (2013-04-24 09:36) [134]

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

Позволяет создать лишь один экземпляр своего класса. И любой отнаследованный от него класс тоже автоматически становится синглтоном (если, конечно, программист сам себе не враг и не изуродовал его поведение, не вызвав inherited в перекрытых им же NewInstance и FreeInstanse).
unit Unit2; interface type TSingleton = class public class function NewInstance: TObject; override; procedure FreeInstance; override; end; implementation uses Classes, SysUtils; var SingletonList: TThreadList; function IndexOfSingleton(SingletonClass: TClass): integer; var i: integer; begin Result := -1; with SingletonList, LockList do try for i := 0 to Count - 1 do if TObject(Items[i]).ClassType = SingletonClass then begin Result := i; Exit end finally UnlockList end end; { TSingleton } procedure TSingleton.FreeInstance; var i: integer; begin with SingletonList, LockList do try i := IndexOf(Self); if i < 0 then Exit; inherited; Delete(i); finally UnlockList end end; class function TSingleton.NewInstance: TObject; var i: integer; begin with SingletonList, LockList do try i := IndexOfSingleton(Self); if i < 0 then begin Result := inherited NewInstance; Add(Result) end else Result := Items[i] finally UnlockList end end; initialization SingletonList := TThreadList.Create; finalization SingletonList.Free end.

← →
DevilDevil © (2013-04-24 10:11) [135]

> Юрий Зотов © (24.04.13 09:36) [134]

при всём уважении, но

type TMySingleton = class(TSingleton) Name: string; end; ... var S1, S2: TMySingleton; begin S1 := TMySingleton.Create; S2 := TMySingleton.Create; S1.Name := "Делай раз"; S1.Free; S2.Name := "Делай два"; // AV S2.Free; end;

Если честно, я так и не понял цимус такого класса-синглетона

← →
Компромисс1 © (2013-04-24 10:35) [136]

Кстати, тут weak reference напрашивается.

← →
Аббат Пиккола (2013-04-24 11:19) [137]

sniknik © (24.04.13 08:19) [130]

> Лучший способ решить проблему - ликвидировать саму проблему.
а она ликвидируется?
стоят двое на остановке спорят
- по моему, туда где мы вчера бухали, не помню куда, нужно ехать на 5-ом автобусе, конечная остановка...
- а по моему, тоже не помню, на 7-м, тоже конечная...
...
- ликвидируйте проблему, езжайте на такси!
- ???

Если один из спорящих помнит, что "вчера бухали в ресторане с каким-то птичьим названием", то таксист может сказать "господа, это ресторан "Орлы", это конечная 7-го автобуса!". Сами же спорящие, опираясь лишь на эту информацию, задачу не решат. Хотя и могут придумать кучу извращенных вариантов типа "сядем на что попало, какая разница, где сегодня бухать".

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

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

← →
Компромисс1 © (2013-04-24 11:22) [138]

Варианты:
1) Я умру молодым
2) Я умру немолодым
Мне не нравится ни один из вариантов, значит Бог есть и я буду жить вечно :)

← →
Ega23 © (2013-04-24 11:32) [139]

> Мне не нравится ни один из вариантов, значит Бог есть и
> я буду жить вечно :)

Так они и проповедуют бессмертие души. если чо.

← →
sniknik © (2013-04-24 11:40) [140]

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

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

← →
DevilDevil © (2013-04-24 11:43) [141]

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

Задача - иметь 2 разных режима работы библиотеки
Первый режим универсальный, второй режим - синглетон конкретного типа с конкретным именем
Найди решение лучше, чем использовать дифайны

← →
Компромисс1 © (2013-04-24 11:49) [142]

> Так они и проповедуют бессмертие души. если чо.

Я знаю. Всегда было интересно, как к религии приходят умные вроде бы люди. Вот оно как, Петрович (с)

← →
Аббат Пиккола (2013-04-24 11:50) [143]

Все зависит от практики будущего применения модуля. Согласны?
Если предполагается модуль продавать, то может оказаться, что исходный вариант с базовым классом TFoo устраивает 99% потребителей данного продукта. А для тех, кто недоволен "ограничениями", имеется define. что превращает их в "довольных", так как они не просто юзают этот модуль. но и могут творчески развить класс TFoo, получая свою зарплату незадаром. Все довольны.

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

Мне видится спор так. Автор полагает, что 100% потребителей будут удовлетворены функциональностью TFoo. Его заботит лишь красота реализации. А его оппонент хочет оставить за потребителями иную возможность тоже. Мне кажется, что оппонент прав. Иначе спор бы и не возник вообще.

При всем моем искреннем уважении к автору вопроса.

← →
sniknik © (2013-04-24 11:53) [144]

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

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

← →
Ega23 © (2013-04-24 11:53) [145]

> Найди решение лучше, чем использовать дифайны

Создать файл с настройками и менять там значение.
Настройки должны быть на основе ini-файла, естественно.

← →
sniknik © (2013-04-24 11:57) [146]

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

← →
Аббат Пиккола (2013-04-24 11:59) [147]

2 Компромисс1 © (24.04.13 11:22) [138]

Варианты:
1) Я умру молодым
2) Я умру немолодым
Мне не нравится ни один из вариантов, значит Бог есть и я буду жить вечно :)

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

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

← →
sniknik © (2013-04-24 12:01) [148]

> Создать файл с настройками и менять там значение.
по "Розычу" там и настроек не нужно... просто ты либо используешь его функцию и объект создается, либо нет, тогда не создается, а нужна копия объекта делаешь ее сам... можно ссылаясь непосредственно на тип/класс... все "автоматом".

← →
Аббат Пиккола (2013-04-24 12:04) [149]

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

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

Нет, это не еще одно решение. Вариант "Если же ее нет, тем более бессмысленно беспокоиться о чем-то кроме самой жизни." тоже не нравится некоторым, можно сказать, что это разновидность варианта "Умру немолодым". Поэтому только Бог, и не спорьте, аббат :)

> Задача - иметь 2 разных режима работы библиотеки
> Первый режим универсальный, второй режим - синглетон конкретного
> типа с конкретным именем
> Найди решение лучше, чем использовать дифайны

Легко. Причем оно уже приводилось в этой ветке. Объявление синглтона в отдельном unit. Кому нужно, тот его подключает в uses.

← →
Аббат Пиккола (2013-04-24 12:16) [153]

2 sniknik © (24.04.13 12:01) [148]

Если не считать существенной экономией то, что объект в "реализации Розыча" может и не создаваться, а обратить внимание на другое - на то, что при такой реализации этом объект может быть только классом TFoo, но никак не его наследником, то и обнаруживается главная причина спора.

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

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

Конечно, можно это реализовать через ini, но все опять упрется в тот же вопрос. Нужно дать возможность расширять класс или не нужно.

Если Розыч так уверен, что это никогда не понадобится, чем его не устраивает директива компилятору? Суть ведь вовсе не в том, как реализовать саму инициализацию. Через функцию или тупо создав объект. Тоже мне экономия... Суть спора в ином. Дать возможность изменить класс глобального объекта или не дать.

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

> Легко. Причем оно уже приводилось в этой ветке. Объявление
> синглтона в отдельном unit. Кому нужно, тот его подключает
> в uses.

альтернатива
но в таком случае ты делаешь 2 модуля библиотеки вместо одного
по мне - удобнее дифайн

ну и потом это первый (универсальный) вариант
в его рамках можно просто объявить переменную "синглетон" где-то у себя в проекте и всё

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

← →
Аббат Пиккола (2013-04-24 12:38) [157]

Синглетон это такой религиозный ритуал? Или есть конкретное применение для глобальной переменной? Если она необходима, придется ее создавать в любом случае. Я бы за экономией места не гнался. Но вместо дифайна, требующего SELF_INITIALIZE я бы сделал негативный дифайн

DISABLE_SELF_INITIALIZE

Если этого дифайна нет, синглетон инициализируется объектом класса TFoo.
чтобы не принуждать никого упоминать SELF_INITIALIZE. Но допустить иное.

> Аббат Пиккола (24.04.13 12:38) [157]
> Но вместо дифайна, требующего SELF_INITIALIZE я бы сделал
> негативный дифайн DISABLE_SELF_INITIALIZE

я думал об этом
скорее всего так и будет в будущем :)

> альтернатива
> но в таком случае ты делаешь 2 модуля библиотеки вместо
> одного
> по мне - удобнее дифайн

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

> DevilDevil © (24.04.13 10:11) [135]
S1 := TMySingleton.Create; S2 := TMySingleton.Create;
Итак, код сработал: S1 и S2 - это ссылки на один и тот же объект. Далее.
S1.Free;
Объект уничтожен и теперь любое обращение к нему (хоть через S1, хоть через S2) выдаст AV. Что и должно быть.

А Вы ожидали чудес? Ожидали, что обращение к уже уничтоженному объекту через переменную с другим именем будет каким-то волшебным образом работать без AV ?

Не будет.

> Если честно, я так и не понял цимус такого класса-синглетона

Если честно, то Вы не понимаете цимус синглтона ВООБЩЕ, а не только ТАКОГО синглтона. Синглтоны используются тогда, когда в программе не нужны несколько одновременно существующих объектов одного и того же класса. Например, это часто бывают какие-то фабрики. В IDE Delphi тоже есть синглтоны - инспектор объектов, палитра выравнивания и т.п.

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

Вот такой цимус.

Нужен третейский судья :) Найти похожие ветки