насколько целесообразно уклоняться от создания глобальных объектов?

Функции уже отменили?

А зачем уклоняться?

Плюсую вопрос.

Если вся ваша софтина пашет над некими данными, которые нужны везде и фактически являются целевыми, почему они не должны хранится в глобальном объекте/переменной? Только потому что где-то написано что это плохо и как важна инкапсуляция?

Лучше таки юзать глобальный геттер, чем голую переменную.

Многопоточность в любом виде.

Что с ней?

Гонки.

Предвидя возможное возражение: глобальный мьютекс — это не менее плохо.

Ну это уже практически == эмулировать объект там где его нет и юзать глобальный «объект». Т.е. смысл ответа не меняет, хотя в общем, да - такой подход более правильный и более unixway'ный.

Почему? Впрчем в таком случае клиент-серверная архитектура вам в помощь.

Почему?

Прощаемся с производительностью, встречаем deadlock'и.

man Singleton.

Как каскадная передача указателя на один и тот же объект поможет этого избежать?

Никак. Мне приходит в голову только то, что архитектуру проектировать так, чтобы глобальных изменяемых сущностей не было. Либо в крайнем случае делать синглтон, с которым общаться исключительно через thread-safe методы, или смотреть в сторону actors/STM.

Иначе в начале каждого сорца нужно капсом писать "не пытайтесь что-то распараллелить".

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

Когда (рано или поздно) окажется, что объектов должно быть всё-таки два, ты застрелишься сорцы править.

А что там в том объекте то?

Я такие объекты добавляю в класс Applicaiton.

Потом получаю его вот так:

SomeObject* Application::instance()->getSomeObject();

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

Не учите людей плохому.

Но ведь в посте выше я вижу то самое плохое.

Не учите людей плохому.

Плохо будет, когда его хелло ворд будет требовать 4 гига оперативы и i7.

Плохо будет, когда его хелло ворд будет требовать 4 гига оперативы и i7.

Ну да, а синглтон спасет от этого.

А твой Application::instance это уже внезапно не синглтон?

Того же мнения, только еще продумать порядок мультипоточной инициализации, или же наложить разумные ограничения

каменнопочечный век, йейбогу в яве давно уже есть ServiceLocator и Dependency Injection

Не ожидал, что ты умеешь делить на ноль =)

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

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

Глобальные штуки - это геморрой. Рано или поздно они испортят тебе жизнь.

Вообще мне непонятно, от чего ты пытаешься уйти. «static-only класс» - это то, что приличные люди делают неймспейсами? Но тогда откуда у тебя указатель на объект?

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

Вообще мне непонятно, от чего ты пытаешься уйти. «static-only класс» - это то, что приличные люди делают неймспейсами? Но тогда откуда у тебя указатель на объект?

у меня class перестал быть static-only и поэтому потребовался указатель на обьект.

Не ожидал, что ты умеешь делить на ноль =)

а некоторые еще умеют делить на -1 так что приложение падает по SIGFPE ;)

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

ну у мого приложения 3 класса напрягающих пробросом указателей: Logger, UI и Config. Назначение и функциональность надеюсь из названия очевидна.

Логгер оставить статичным (во всяком случае используемые методы), Config получать от какого-нибудь главного синглтона типа Application или Core.

каким образом? где ты предлагаешь хранить открытый файл?

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

В одном приложении может быть только одно приложение. ШОК. ФОТО. БЕЗ СМС.

Приложение оно одно единственное и есть. А все остальное им контролируется.

А синглтоны способствуют уменьшению потребляемой памяти?

Не ожидал, что ты умеешь делить на ноль

Конкретизируете?

каким образом? где ты предлагаешь хранить открытый файл?

Получать инстанс логгера внутри статического метода. Или freopen при инициализации.

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

А синглтоны способствуют уменьшению потребляемой памяти?

Меньше используется стек, чтобы гонять указатели по функциям, меньше используется куча (если используется глобальная память для объекта).

Но оно же само синглтон в чистом виде.

В одном приложении может быть только одно приложение. ШОК. ФОТО. БЕЗ СМС.

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

В каком году плюсовики дойдут до DI и IoC?

Я не делю технологии на черное и белое. Синглтон это, чаще всего, плохое решение для класса, но экземпляр приложения в приложении может быть только один. Se la vi.

В одном приложении может быть больше приложений

Как там у вас в параллельной вселенной? Коровы до сих пор кофе дают или перешли на кефир?

Экономить на спичках.

Как там у вас в параллельной вселенной? Коровы до сих пор кофе дают или перешли на кефир?

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

И где же ответ на мое «во-вторых»?

А потом ходют по ЛОРу всякие и плачутся, что всё тормозит.

И где же ответ на мое «во-вторых»?

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

Преждевременная оптимизация до добра не доводит.

А твой Application::instance это уже внезапно не синглтон?

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

Да уже все разъяснилось дальше в треде. Удачи.