Используете ли вы глобальные переменные

Добрый вечер,

используете ли вы у себя в коде глобальные переменные между единицами трансляции и/или в конкретной?

Моё мнение: нужна общая переменная делаем сингтон (+контроль, +гибкость, +ООП, +lazy inizilization).

P.S. Смотрю проекты гитхаба С++ - используют люди глобальные с extern, блэк-джеком и пушками. Смотрю в чём плюсы такого приёма - не вижу. Человеческая лень?

Знаю пример, когда на cpp заводят
но других "удачный" примеров использования - не помню/не знаю.

0

Сообщение от hoggy а что, сингелтоны как то ему противоречат что ли?

Ну так как ты получаешь синглтон-то? Опиши последовательность действий.

Сообщение от hoggy во-первых, разрабатывая по TDD, программист изначально, на стадии проектирования/конструирования предусматривает возможности изоляции и интеграции разрабатываемого механизма. так что вот таких проблем обычно никогда не возникает.

Тут уже я не про TDD. Забудь о нем. Просто чей-то легаси код с синглтонами.

Сообщение от hoggy а во-вторых, если все таки и возникает проблема ненужных зависимостей, то обычно её тривиально разрешают на макросах.

Ну для кого-то может костыли и обычное дело.

Сообщение от hoggy и потом, это же в любом случае не проблема сингелтонов. это проблема не очень опытных программистов.

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

Сообщение от hoggy что за сайд эффект? как именно он вам помешал?

Чтение и запись из файлов/бд.

0

Сообщение от ct0r Ну так как ты получаешь синглтон-то? Опиши последовательность действий.

никак. зачем мне его получать?

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

я апи тестирую, а не детали реализации.

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

Сообщение от ct0r Ну для кого-то может костыли и обычное дело.

почему костыли? вполне простое и рабочее решение.
намного удобнее и проще, чем инъекция зависимостей,
например.

ну и зачем делать сложно,
если можно сделать просто?

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

абсолютно верно.

Сообщение от ct0r Чтение и запись из файлов/бд.

ну и как это вам помешало?

0

Сообщение от Kastaneda Нет, не использую, предпочитаю вот такой простой и надежный подход

а разве это не приводит к постоянному изменению header файла?

0

Сообщение от hoggy никак. зачем мне его получать?

Ну и я про то.

Сообщение от hoggy абсолютно верно.

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

Сообщение от hoggy почему костыли? вполне простое и рабочее решение.

Подозреваю, что мы тут каждый о чем-то своем думаем.

Сообщение от hoggy ну и как это вам помешало?

Потому что для тестов тогда нужна определенная внешняя среда. Например, машина должна иметь возможность лазить в эту бд. Или на самой машине надо настроить бд. И нужен скрипт, который генерит конфиги, а после тестов чистит созданные файлы. Это все вместе складывается в рутинный гемор. Бесит короче.

1

Сообщение от ct0r Ну и я про то.

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

я задал вам вопрос: зачем вам это нужно?

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

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

Сообщение от ct0r Подозреваю, что мы тут каждый о чем-то своем думаем.

я прекрасно понял вашу точку зрения.

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

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

Сообщение от ct0r Потому что для тестов тогда нужна определенная внешняя среда. Например, машина должна иметь возможность лазить в эту бд. Или на самой машине надо настроить бд. И нужен скрипт, который генерит конфиги, а после тестов чистит созданные файлы. Это все вместе складывается в рутинный гемор. Бесит короче.

при чем здесь вообще сингелтон?

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

вот вот казалось бы, и при чем тут сингелтоны?

0

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

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

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

Сообщение от hoggy так можно о чем угодно сказать.

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

Сообщение от hoggy использование дефайнов препроцессора для тестовой сборки - в разы проще.

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

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

0

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

и при чем здесь сингелтон?

вот есть сайд-эффект: механизм создаст файлик на жестком диске.
и вы об этом знаете.
какая разница каким именно образом это произошло?

Сообщение от ct0r Какой случай может заставить меня использовать множественное наследование для быстрого хака?

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

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

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

давайте не использовать указатели,
не использовать динамическую память...

с такими превентивными мерами вам нужно писать на бейсике каком нибудь.

Сообщение от ct0r Зачем нужно разбрасывать ifdefы по коду класса, если можно все сделать в одном месте?

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

Сообщение от ct0r я в общем про что: легче запретить использовать синглтоны по всей кодовой базе, чем постоянно следить за тем, что их правильно готовят и используют менее опытные товарищи. Потенциально получаемый от синглтонов профит не оправдывает усилий, имхо.

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

0

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

Зря вы так относитесь к превентивным мерам относительно сингелтонов.
Скажите сколько раз вы искали по проекту "<something>::getInstance()" ? что бы понять насколько болезнено будет слазить с него, сколько разработчиков привязалось к этому сингелтону? И всё обычно потому что люди жутко ленивые создания, вместо протягивания между парой "модулей" этого "синглетона" решили сделать его "статиком". Лень протягивать явно руками - ну налабайте себе какую-нить тулзу-хелпер, хоть на макросах, когда потребуется кастомизация - копипастой поправите "макрос" в этом случае.

Давайте взглянем что такое сингелтон с высоты полета - это глобальная, не расширяемая ООП инструментами, шина взаимодействия внутри приложения, именно взаимодействия, это не глобальные данные, и не глобальный код, т.е. в сингелтоне(для которых работают мои превентивные меры) практически всегда присутствует состояние и какой-то код. Кто готов завести объектно ориентированный сингелтон для того чтобы потом в нём заводить бесчисленное множество флажков и превратить этот лже ООП класс в процедурный божественный объект?

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

А использовать глобальные состояния нужно только когда вы уверены на 146%, что это "состояние" не потребуется третьим модулям.
Например:
Класс генерации атласа(текстуры/картинки) шрифта для текстовых полей, нужен один для всех полей, но больше нафиг никому не сдался - можно сделать сингелтон и потом молиться, чтобы никто не придумал какой-нить эффект через изменение этого атласа(и ни в коем случае не говорите об этом менеджеру, а-то он придумает )

0

Сообщение от Nosey Скажите сколько раз вы искали по проекту "<something>::getInstance()" ?

ни разу.

Сообщение от Nosey что бы понять насколько болезнено будет слазить с него, сколько разработчиков привязалось к этому сингелтону?

зачем с него слазить?

Сообщение от Nosey Давайте взглянем что такое сингелтон с высоты полета - это глобальная, не расширяемая ООП инструментами, шина взаимодействия внутри приложения

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

однако разница существует с точки зрения деталей внутренней реализации:
в отличие от чисто-сишного модуля,
синглетон - объектно ориентированный компонент.
он прекрасно расширяется ооп-средствами.

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

Сообщение от Nosey Кто готов завести объектно ориентированный сингелтон для того чтобы потом в нём заводить бесчисленное множество флажков и превратить этот лже ООП класс в процедурный божественный объект?

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

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

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

вообще не распарсил этот поток сознания.
сингелтон - и есть глобальный объект,
вообще то.

Сообщение от Nosey А использовать глобальные состояния нужно только когда вы уверены на 146%, что это "состояние" не потребуется третьим модулям.

это не просто не обязательное,
а вообще не имеет значение к сингелтоновским метрикам.

единственная и достаточная причина для того,
что бы сделать сингелтон синглетоном:
положительно ответить на себе на вопрос:
существование 2х и более экземпляров механизма не имеет смысла?

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

я бы не стал так рисковать.
недавеча был такой случай.
тоже со шрифтами))

есть класс коллекции шрифтов.
живет он в свойствах главной формы
(это не принципиально, хоть в сингелтон его пихайте).
и умеет раздавать ссылки на свои шрифты.

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

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

все старые потребители останутся без изменений.
они будут ссылаться на шрифты со старыми именами.

а все новые смогут ссылаться на новый шрифт по его уникальному имени.

0

hoggy, Судя по всему вашему сообщению и особенно последнему боевому примеру, вы также используете превентивные меры при создании глобального объекта. А если точнее вы не используете глобальные объекты поэтому у вас и нет проблем. Но мы всё-таки в ветке для начинающих и в этой ветке говорить, что сингелтон это отлично - несколько опасно.
Например вы точно не упакуете в сингелтон глобальный какой-то конфиг приложения(да и вообще у вас не будет такого конфига, вы его разобьете на несколько), вы его руками протянете, либо через компоновщик "автоматически" протянете, либо сразу целую группу "конфигов", либо в конце концов напишите сингелтон реализующий State/Visitor(или что-нить поведенческое по вкусу) + Facade, и не будете знать бед, но в какой ветке мы это пишем ?

Сообщение от hoggy словно сингелтон обязательно должен быть божеством.

И учитывая верхнее и повторяясь что люди ленивые создания прокомментирую это вот так:
Сингелтон это молодое божество, ну в 94% случаев.

0

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

я не согласен.

то есть, я не считаю, что сингелтон - это отлично.
не нужно ударяться в другую крайность

напротив, именно здесь нужно говорить о "природе" вещей.
и развеивать мифы.

сингелтон по своей природе ничем не отличается от обычного сишного модуля.

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

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

а потом новичок вырастает, впитывая это все с материнским молоком.

а потом реально так считает.
только вот он не в состоянии объяснить:
а почему так?

не видит профитов использования, и не умеет границы применимости.

Сообщение от Nosey А если точнее вы не используете глобальные объекты поэтому у вас и нет проблем.

ещё как использую.

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

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

почему не подозреваю об их существовании - спросите вы?
да потому что они не приводят ни к каким проблемам,
и не создают "сюрпризов" в виде неожиданных сайд-эффектов.
такова уж их реализация - по уму сделана.

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

Сообщение от Nosey Например вы точно не упакуете в сингелтон глобальный какой-то конфиг приложения

ещё как упакую.
даже более того:
на сопровождении есть как минимум одна софтина,
где именно через сингелтон и была реализована
поддержка конфигурации.

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

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

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

Сообщение от Nosey Сингелтон это молодое божество, ну в 94% случаев.

за всю свою практику, я ни разу не наблюдал подобного.

Сообщение от Nosey Bitmap шрифты?

местный велосипед, который умеет работать со шрифтами mfc, и др.

0

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

Согласен.

Сообщение от hoggy даже больше: некоторые из моих механизмов порождают бесчисленное количество сингелтонов скрытно для программистов.

А вот и слово скрытно, это важное дополнение к

Сообщение от hoggy положительно ответить на себе на вопрос: существование 2х и более экземпляров механизма не имеет смысла?

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

Сообщение от hoggy ещё как упакую. даже более того: на сопровождении есть как минимум одна софтина, где именно через сингелтон и была реализована поддержка конфигурации. это - программа "администратор баз данных", для нужд компании. в гуях выпадает список, можно выбрать имя соединения. ну и там сразу же получаем пароль/логин, права и тп. это соединение становится "активным".

Т.е. этот сингелтон читает из файла троицу "соединение/пароль/логин" и раздает их нужнающимся?
В таком случае мне кажется что сингелтон тут и не нужен )) Ведь после установления соединения все эти данные практически не используются, у вас же есть модель приложения чтобы хранить имя пользователя?
А также это очень маленький сингелтон, по факту раздающий константные строки(ну это как хелловорд же ), обладающий малой вероятностью что его нужно будет расширять, единственно что приходит в голову так это еще одна верхняя абстракция доступов а также группировка, без чего можно прожить достаточно долго.
Но давайте представим по этому примеру следующую картину:
1) У нас нет модели, т.е. много клиентского кода завязано на этот сингелтон.
2) Этот проект подал хорошие надежды и мы его разрабатывали уже как >>5 лет, т.е. завязано реально много.
3) Теперь юзеры говорят что у нас слишком много соединений мы хотим их структурировать.
Что нам придется делать?
-) Отвязываться от сингелтона. (ненене и так поработают, тоже мне много у них соеденений )
-) Раздувать сингелтон. (нет ничего более постоянного чем временное)
Так вот перед тем как создать сингелтон все должны как следует подумать, и потом еще подумать, и даже еще не помешает подумать.

И ведь эта ситуация не такая редкость, не так ли?

0

Сообщение от Nosey Сингелтон локальный

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

но почему то никто при этом не подумал:
а может быть существует другой путь?
может быть есть техники безопасного использования?

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

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

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

Сообщение от Nosey Т.е. этот сингелтон читает из файла троицу "соединение/пароль/логин" и раздает их нужнающимся?

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

Сообщение от Nosey Ведь после установления соединения все эти данные практически не используются

используются.

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

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

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

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

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

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

Сообщение от Nosey у вас же есть модель приложения чтобы хранить имя пользователя?

ну так, сингелтон и реализует эту саму модель.

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

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

во всем остальном,
он выдает наружу любому желающему информацию об активном соединении.

Сообщение от Nosey Что нам придется делать?

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

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

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

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

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

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

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

значит, пользователь тыкает на кнопочку "создать бд",
и приводит в действие целый конвейер процессов,
по созданию каталогов, табличных пространств, и тп.

пользователи хотят видеть, что происходит?

то есть, он захотел панельку, где был бы вывод наподобие:

"создаю базу данных..." "построение промежуточных каталогов... успешно" "создание табличного пространства... успешно" "создание базы данных успешно завершено!"

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

в реализации апи просто сделал вызовы этого логгера.
отлично. все довольны.


и тут внезапно, пользователи захотели получить возможность самим влиять на течение процесса:
они захотели "политики".

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

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

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

и вот здесь я встрял.

мне пришлось:

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

2.
сделать его не сингелтоном,
и соотвественно, протягивать по всем функциям как параметр.

3.
реализовать дополнительные функционал,
с помощью которого разруливался вопрос:
игнорировать/аборт

то есть, это вылилось в жесткий и беспощадный рефактор.

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

2

never

0

Сообщение от hoggy какая разница каким именно образом это произошло?

Мне не важно, как это произошло. Мне нужно, чтобы этого не происходило в принципе, если я так захочу.

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

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

Сообщение от hoggy давайте не использовать указатели

Давайте. Будем использовать только там, где без них не обойтись. Отличная идея.

Сообщение от hoggy не использовать динамическую память...

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

Сообщение от hoggy что б дефайном подменить реализацию, обычно вполне достаточно одного дефайна.

А маленький примерчик можно?

Сообщение от hoggy то есть, вы считаете, что проще запретит использовать модули с сишным апи, чем следить за своими младшими коллегами? и профит от этого использования не оправдывает усилий?

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

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

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

1

Сообщение от ct0r Мне не важно, как это произошло. Мне нужно, чтобы этого не происходило в принципе, если я так захочу.

как бе синглтон тут никак не мешает.
это вообще из другой области.
это из области дизайна самого механизма.

то есть, например, мы ему выставляем настройку: "не делай вот это".
ну или "делай вот это".
или "когда случится это, сделай вот это".

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

Сообщение от ct0r Именно. Использование сишной либы - только при необходимости. Когда просто нет альтернатив с таким функционалом, а свой велосипед писать долго. И то сишка изолируется от плюсового кода, а не втыкается в него во все места.

ну что значит "изолируется" ?

вот есть сишная функция: create_directory
и как вы изолируете её от крестового кода?

или другой более реалестичный вариант:
есть sax-parser под названием expat.
позволяет грузить в потоке xml

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

вас это никак не смущает?

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

Сообщение от ct0r Давайте. Будем использовать только там, где без них не обойтись. Отличная идея.

позвольте мне вас перефразировать:

"давайте. будем использовать сингелтоны только там, где без них не обойтись. отличная идея".

а теперь позвольте мне себя поправить:

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

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

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

как вы считаете?

Сообщение от ct0r Тоже хорошее предложение. Было бы замечательно. Но увы и ах, без нее редко когда можно обойтись.

мы можем не использовать многотопочность.
вот где кладезень ошибок!!!

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

но блин, она так сильно морочит код и программистов...

м?

Сообщение от ct0r А маленький примерчик можно?

Сообщение от ct0r Если берем чужую сишную либу, то оборачиваем во вменяемый C++, и пользуй кто хочет.

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

или "если мы обернули сингелтон в наш класс, то он уже или не совсем сингелтон, или не совсем зло".
м?

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

нет, вы не поняли.

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

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

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

1

Сообщение от hoggy но если она есть, значит

Значит, что-то пошло не так, ибо любая программа для машина Тьюринга может быть переписана в виде функции исчисления Чёрча. Всю работу с глобальным состоянием всегда можно описать в тонком слое, в функции main, например.

1

Сообщение от mporro Значит, что-то пошло не так, ибо любая программа для машина Тьюринга может быть переписана в виде функции исчисления Чёрча. Всю работу с глобальным состоянием всегда можно описать в тонком слое, в функции main, например.

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

во-первых, мы все таки о чем то реальном-приземленном говорим,
а не о сферических конях в теории Тьюринга.

никто ж в здравом уме не пихает реально все в один main.

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

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

такое требование типично для всяких логгеров.
в стандартной библиотеки его реализует std::cout.
который можно безопасно звать в любое время,
включая конструкторы статических объектов.
то есть ещё до запуска функции main.

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

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

рассмотрим пример использования:

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

а никак, только через глобальное состояние.

можно ещё придумать ситуации,
когда сингелтон - необходимость.

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

0

hoggy, Вы правда верите в то что пишите? или просто играете роль плохого копа? Если последнее, то мне кажется, что уже хватит плохого копа в этой теме

Сообщение от hoggy какие тут могут быть проблемы? тут вообще ничего менять не придется. достаточно нарастить новое мясо.

И когда мы остановимся наращивать мясо? Есть какой-то критерий? И что мы будем делать когда остановимся его наращивать?

Сообщение от hoggy вот как вы прикажите функции в таких условиях связываться с механизмом, который знает про подписчиков?

Вот так:
Мы же за ООП? В котором глобальные состояния сведены к минимуму и наша лень не столь сильна.

0

Сообщение от Nosey Вы правда верите в то что пишите?

я не верю, я знаю.
и мне не понятна ваша реакция.
что вас смущает?

Сообщение от Nosey И когда мы остановимся наращивать мясо? Есть какой-то критерий?

но очевидно жеж.

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

Сообщение от Nosey И что мы будем делать когда остановимся его наращивать?

чем нибудь другим займемся?

Сообщение от Nosey Мы же за ООП? В котором глобальные состояния сведены к минимуму и наша лень не столь сильна.

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

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

откуда класс бизнес-логики узнает про каких то там подписчиков?
подписчики - деталь реализации системы сообщений.

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

нет, вы конечно можете сделать что-то вроде:

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

посмотрите в сторону mfc, qt, boost::signals2, и многие другие.
никто из них не требует от классов бизнес-логики
наследоваться и реализовывать какие то дураццкие интерфейсы.
и для посылки очередного типа сообщения,
они не требуют того, что бы это сообщение обязательно являлось
классом унаследованным от интерфейса сообщений.

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


годный дизайн выглядит так:

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

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

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

0