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

M>Переписывать.
M>Зато у них есть работающая программа.
M>Если бы они сразу в неё попытались впихнуть всё заранее — то работающей программы у них бы не было.
M>Preliminary optimization за что ругают?

M>90% программ не испытывают проблем со стандартным потоком вывода. 9 из оставшихся 10 — решают эту проблему на уровне batch файла
M>или библиотек (которые такую возможность чаще всего дают).
M>Начинать писать программу предусматривая, что может быть понадобится перенаправление в файл, да ещё сильно нестандартное перенаправление — это не самое удачное решение.

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

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

M>>А List.Nil (в связном списке) — это кто, не синглтон? Чем он плох, как единственный объект "пустой список"? Впрочем, про true и false я уже приводил примеры. Тоже — уникальные, глобальные и всё такое.
WH>У них нет identity!

Куда делась?

WH>Про эффективней просто не правда.

У нас разный опыт.

WH>За последние несколько лет я написал всего один goto по делу и еще два по приколу. А если бы у меня были локальные функции с гарантированной раскруткой хвостовой рекурсии то я вобще ни одного бы не написал.

И что? А я больше раз. По делу.

WH>С глобальными переменными таже фигня.
WH>Если научится писать без них то они становятся просто не нужны.

Можно, но не нужно. Можно носить с собой контекст в параметре каждого метода, можно ложить контекст в локальную переменную треда, много ещё чего можно. Но не нужно. А если понадобится — то недолго переделать.

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

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

V>>А можно реальный жизненный пример, в которм применение синглтона оправдано и дает _преимущества_ перед другими решениями, а не равнозначно с ними. С примерами, где синглтон имеет недостатки у меня проблем нет. А вот с преимуществами — что-то ничего в голову не лезет

M>Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре.

Жить в одном экземпляре и синглтон — это не одно и тоже. Обычно под синглтоном понимают конкретную его реализацию (я имею ввиду со статическим методом). Чем это лучше варианта, когда доступ к объекту получаем не через статический метод класса, а через обычный метод обычного объекта?

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

M>Переписывать.
Несколько метров кода?
Круто!

M>Зато у них есть работающая программа.
Нет у них работающий программы.
Они из нее тараканов выловить не могут. Ибо в логах чехорда.
И исправить это быстро невозможно.

M>Если бы они сразу в неё попытались впихнуть всё заранее — то работающей программы у них бы не было.
Не нужно впихнуть все. Нужно не забывать о том что код придется поддерживать. И всеми силами стремится к тому чтобы поддерживать его было легко.
Синглетоны заведомо осложняют поддержку. Причем всегда и сильно.

M>Preliminary optimization за что ругают?
А что делают за написание заведомо неработоспособных решений?

M>Начинать писать программу предусматривая, что может быть понадобится перенаправление в файл, да ещё сильно нестандартное перенаправление — это не самое удачное решение.
Блин. Просто афигенное усложнение...
Вместо:

void generate()
{
    ...
    std::cout << "bla-bla";
    ...
}

int main()
{
    generate();
}

пишем:

void generate(std::ostream& out)
{
    ...
    out << "bla-bla";
    ...
}

int main()
{
    generate(std::cout);
}

И все! Больше никаких проблем с выводом в файл. Или в поток в памяти.

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

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

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

M>>Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре.

V>Жить в одном экземпляре и синглтон — это не одно и тоже.

Конечно это разные вещи. А вот жить гарантированно в одном экземпляре — это одно и то-же.

V>Обычно под синглтоном понимают конкретную его реализацию (я имею ввиду со статическим методом).

То есть ты себе что-то понимаешь, и с этим чем-то споришь.

V>Чем это лучше варианта, когда доступ к объекту получаем не через статический метод класса, а через обычный метод обычного объекта?

Тем, что есть вещи семантически уникальные. Как только их становится несколько — это нарушение контракта и дизайна.
Чаще всего таких объектов вообще не надо иметь (в смысле — не обязательно их иметь). Раз он один, уникальный, то и не нужен он.
Единственный существующий пул тредов можно заменить набором статических методов и переменных.
List.Nil можно заменить чем-то вроде нулевого указателя и т.д.
А шаблон singleton применяют в случаях, когда дизайн (приложения, библиотеки, метода) требует объекта, инстанса — просто
нужно передать ссылку на объект. Т.е. ограничение языка программирования, его средств. Шаблонные решения потом, зачастую,
входят в сам язык программирования. Скажем, singleton вошёл в Scala как object (в отличие от их class-а).
Вошёл именно потому, что это действительно самантическая и удобная абстракция, а не какой-то buzz-word.

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

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

M>>>Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре.

V>>Жить в одном экземпляре и синглтон — это не одно и тоже.

M>Конечно это разные вещи. А вот жить гарантированно в одном экземпляре — это одно и то-же.


V>>Обычно под синглтоном понимают конкретную его реализацию (я имею ввиду со статическим методом).

M>То есть ты себе что-то понимаешь, и с этим чем-то споришь.

V>>Чем это лучше варианта, когда доступ к объекту получаем не через статический метод класса, а через обычный метод обычного объекта?

M>Тем, что есть вещи семантически уникальные. Как только их становится несколько — это нарушение контракта и дизайна.
M>Чаще всего таких объектов вообще не надо иметь (в смысле — не обязательно их иметь). Раз он один, уникальный, то и не нужен он.
M>Единственный существующий пул тредов можно заменить набором статических методов и переменных.
M>List.Nil можно заменить чем-то вроде нулевого указателя и т.д.
M>А шаблон singleton применяют в случаях, когда дизайн (приложения, библиотеки, метода) требует объекта, инстанса — просто
M>нужно передать ссылку на объект. Т.е. ограничение языка программирования, его средств. Шаблонные решения потом, зачастую,
M>входят в сам язык программирования. Скажем, singleton вошёл в Scala как object (в отличие от их class-а).
M>Вошёл именно потому, что это действительно самантическая и удобная абстракция, а не какой-то buzz-word.

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

Во-вторых, при использовании синглтона делается излишне смелое предположение, что объект обязан быть уникальным во всем мире, в любых условиях и любых вариантах использования. Это черевато граблями. Правильнее вообще не делать предположений об уникальности объекта (99%), а если и делать, то только в _рамках_ некоторого ограниченного контекста (1%).

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

SS>А можно в двух словах, что это такое, читал Wikipedia, не очень хорошо понял.

Это способ построения приложения, в котором логика связывания объектов выносится из этих объектов в отдельные сущности.
Грубо говоря, это некие фабрики, которые не только создают объекты, но и инициализируют одни объекты другими.
Это конечно совсем в двух словах.
Можно почитать в документации по spring framework. Там в первых главах это популярно написано.

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

WH>Давай не путать синглетон и объект живущей в одном экземпляре.
WH>Это сильно разные вещь.

WH>IOC какраз используется для того чтобы мысль о синглитонах даже не возникала.

Сложно перепутать.
Синглетон, по названию своему — "объект живущей в одном экземпляре".

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

V>Жить в одном экземпляре и синглтон — это не одно и тоже.

начит мы говорим о разных вещах.

V> Обычно под синглтоном понимают конкретную его реализацию (я имею ввиду со статическим методом). Чем это лучше варианта, когда доступ к объекту получаем не через статический метод класса, а через обычный метод обычного объекта?
Я не готов об этом с вами говорить. Тут недавно пробегали мои мысли по извесным реализациям сингелтонов, если интерессно — поищите.

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

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

M>>Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре.
WH>А мне очевидно что одним пулом потоков обойтись можно далеко не всегда.
Я этого не утверждал.

WH>Надеюсь про дедлоки на пулах потоков расказывать не нужно?
не рассказывай.

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

Востановим ход разговора:
V>>>>А можно реальный жизненный пример, в которм применение синглтона оправдано и дает _преимущества_ перед другими решениями, а не равнозначно с ними. С примерами, где синглтон имеет недостатки у меня проблем нет. А вот с преимуществами — что-то ничего в голову не лезет
M>>>Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре.
WH>>А мне очевидно что одним пулом потоков обойтись можно далеко не всегда.
M>Я этого не утверждал.
Так что-же ты хотел сказать приводя пул потоков как хороший пример синглетона если очевидно что синглитоном его делать нельзя?

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

WH>Так что-же ты хотел сказать приводя пул потоков как хороший пример синглетона если очевидно что синглитоном его делать нельзя?

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

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

M>Очевидно что для эфективности такой объект должен жить в одном экземпляре. Остальное ты сам додумал.
Какой еще один экземпляр?
Какая еще эффективность?
Ты вобще о чем?
С одним пулом в некоторых ситуациях могут быть дедлоки.
А если есть дедлоки то программа не работает.

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

WH>Какой еще один экземпляр?
WH>Какая еще эффективность?
WH>Ты вобще о чем?
WH>С одним пулом в некоторых ситуациях могут быть дедлоки.
WH>А если есть дедлоки то программа не работает.

Могу только рекомендовать сменить имплементацию на коректную.

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

M>Могу только рекомендовать сменить имплементацию на коректную.
Реализацию чего?

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

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

M>>Могу только рекомендовать сменить имплементацию на коректную.
WH>Реализацию чего?

Пула потоков в котором бывают дедлоки.

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

M>Пула потоков в котором бывают дедлоки.

Реализация корректна.
Проблемы с пулами фундаментальны.
Просто сама модель пулов подвержена дедлокам.
Сам поймешь как или таки объяснить?

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

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

M>>Пула потоков в котором бывают дедлоки.
WH>
WH>Реализация корректна.
WH>Проблемы с пулами фундаментальны.
WH>Просто сама модель пулов подвержена дедлокам.
WH>Сам поймешь как или таки объяснить?

Я думаю это проблемы твои персональные. Мне не интерессно, если хочешь об этом поговорить лучше заведи топик новый. Спасибо за понимание.

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

M>Я думаю это проблемы твои персональные.
Как скажите мусье де'Артаньян.

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