гы нашел кое что
http://forum.vingrad.ru/index.php?showtopi...st&p=932745
http://lib.profi.net.ua/doc/info_sites/vis...m/singleton.htm
  

Синглтон - это вариант глобальной переменной, но создать второй объект такого же типа нельзя.  В этом собственно и вся разница. И с точки зрения клиента объект класса синглтон владеет сам собой.
А применять сингл можно много где: keboard, screen, printer и т.д. Создавать вторые экземпляры таких классов неразумно, а порой и abnormal operation.

Ну правильно, а дельфисты без шаблонов спокойно обходятся :-)


тут про шаблоны всякие для delphi


Опишу, как в Delphi (VCL) реализована работа с разными графическими форматами, там используется все фичи, о которых я писал   

Так вот, в graphics.pas декларированы классы TBitmap, TGraphic, TPicture и еще несколько. TGraphic это абстрактный класс с общим для картинок интерфейсом, типа читать/писать из файла/стрима, рисовать себя на канве итд. TBitmap наследован от TGraphic и читает *.bmp. 
TPicture имеет почти тот же интерфейс, как и TGraphic, но работает с любым известным форматом, так как выбирает нужного потомка TGraphics из известных.
Работает это примерно так: в секции initialization потомка TGraphics вызывается функция из graphics.pas, которая регистрирует новый формат. Когда TPicture надо открыть файл, она перебирает все форматы, вызывая статический метод, который возвращает nil если формат не поддерживается, или метакласс TGraphicClass (= class of TGraphics). С помощю этого метакласса TPicture создаёт нужный класс, примерно так (код не из graphics.pas):

Это можно реализовать на C++ с помощю Factory pattern, но не так элегантно и коротко   

А вот что ИМХО нельзя реализовать, так это удобное использование, если например хочется поддержки png, gif, tiff итд, надо скачать что-то типа TPNGGraphic, TTIFFGraphic, TGIFGraphic и просто добавить их в uses, и все компоненты VCL (и собственные), использующие TPicture начнут поддерживать png, tiff, итд без переделок в коде.

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

ЗЫ:
Вспомнил еще одну фичу: properties

ЗЗЫ:
Кстати, в delphi с помощью properties реализуется различный доступ на элементы списков при чтении/записи, как в C++ operator[]-ом.

Это сообщение отредактировал(а) nickless - 1.12.2006, 01:26

[offtop]

Цитата(Romikgy @  30.11.2006,  10:45 )

А терь точнее , или я своими высказываниями лично вас чем то оскорбил?

Вообще-то да. Но, надеюсь, не более я чем я вас 

Цитата(Romikgy @  30.11.2006,  10:45 )

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

А что, кто-то наезжал? Или мое обращение на "ты" ты воспринимаешь как неуважительное отношение с моей стороны?
[/offtop]


Так с первых постов я именно об этом и пытался объяснить, вспомни: я говорил об одном алгоритме для множества различных типов.


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


И я говорил, что не сомневаюсь в твоих способностях переписать на дельфи. Даже объем написанного кода будет такой же 
Здесь другое. Посмотри, пара static методов, а вся арифметика на inline. Как я уже говорил, классы для низкоуровневых алгебраических структур самые времязатратные, на их методы приходится примерно 85-90% работы алгоритмов библиотеки.

По поводу перевода кода самих методов точно утверждать не буду, только догадка. Например:

и паскалев аналог:

почему-то мне кажется, что при компиляции последний вариант даст больше машинных команд. Кста, в приведенном сишном цикле ровно в sizeof(int)/sizeof(char) раза меньше итераций, чем в переведенном варианте. (хотя, конечно, мой перевод неэффективен, возможно ты сделал бы лучше).

Ну и в любом случае, ради десятка машинных команд -- делать на них call по [хз] раз в милисекунду -- непозволительная растрата.


Так я ж кажется говорил про менеджер памяти. Немножко оптимизирован для работы с большим набором мелких однотипных объектов. Ну вот он: allocator.h, allocator.cxx.


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



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



Это сообщение отредактировал(а) Artemios - 1.12.2006, 04:06

На сегодняшний день , это уже не могут быть синглтонами, может быть более 1 клавы , экрана, и тем более принтера, имхо применение их (в данном примере) нелогично!

плз сцылку, на мое оскорбление вам? (дабы не обижать остальных участников форума, буду учится на своих ошибках)

ваши высказывания подводят мя к такому выводу (не последние!)

нет, обращатся можете как вам будет угодно!

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

Хоть чтото 

тема топика (кса можете прочитать сверху) не дискуссия о матиматике, а о целесообразности перехода от Дельфи на С++ (ВООБЩЕ!!!!!)

и что, нет методов статик в дельфи, да и инлайн другой, имхо можно обойтись и без них!

с этой точки зрения да , возможно скорость для вас и критична, но инлайн ф_ции всегда страдали одним недостатком! конечный размер довольно быстро растет!

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

Тебе же карты в руки.


Кса прочитал. По теме (ВООБЩЕ) высказался в своем первом здесь посте. А далее кто-то  зацепился за сравнительную эффективность использования дельфи в математике, начал требовать доказательств, примеров кода -- в этом ключе и идет наш частный разговор, так что не надо увиливать, будто я зациклился на одной математике и на конкретных расчетах. 
Я свою позицию в этом (ЧАСТНОМ) вопросе обосновал, поэтому имею право повторить свой вопрос: примеры задач математики, где использование дельфи эффективней, нежели c++ -- где? Нет -- считаем вопрос дельфи vs математика закрытым.

хммм .... к чему бы это ....


Молодец

имхо мателатика везде одинаковая, 

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

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

Считайте.... ваше право!

необоснованно.

Угу, к байтам, битам, а далее к машине Тьюринга 
К сожалению, мой собеседник не имеет представления о современной алгебре. Вынужден констатировать бессмысленность всего предыдущего диалога между нами.
Вопрос: кой смысл было поднимать спор при отсутствии осведомленности и при нежелании обосновывать свои заявления?

Возможно....

спор был об разности С++ и дельфи, а не о 

!!!!!
PS очень странный ваш последний пост после

по поводу темы????

громкие заявления  , не согласен

GoF

Коряво, имхо
nickless
Сложно мне понять до конца, как там синглетон реализован (слава богу с Делфи давно не работал   )
как то там все сложно   
вот вполне безопасный для однопоточного использования синглетон из 9 строчек


не придирайся к конкретным примерам
по теме: любой менеджер чего-либо резонно сделать синглетоном

Это сообщение отредактировал(а) MAKCim - 1.12.2006, 17:21

даже менеджер дельфи 

у каждого свое мнение

что мешает мне сделать 
singleton с1, c2 ;
?

Это сообщение отредактировал(а) Romikgy - 1.12.2006, 17:33

сделай
то, что предложил nickless, прямо скажем несколько больше чем 9

Добавлено @ 17:36 

private конструктор
сей код не будет компилироваться

Это сообщение отредактировал(а) MAKCim - 1.12.2006, 17:36

100% согласен , но можно   

он даже так не хочет 

только так

упс   
в код добавить надо


Это сообщение отредактировал(а) MAKCim - 1.12.2006, 20:45

В принципе там просто считаются ссылки, и объект создаётся только один раз.
Кода 33 строчки, ровно в 3 раза больше чем в твоём последнем варианте