Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Caracrist, Вы писали:
C>>Во вторых ваша система полетит при мульти трединге. E>А разве на iPhone такое бывает?
Здравствуйте, agg, Вы писали:
agg>Здравствуйте, встала задача написать Singleton для iPhone, посмотрел иходник из Loki и вот что получилось:
agg>Но никакие финты не помогли, такое предчувствие что я переработал и немного затупил, подскажите пожалуйста как правильно занулить статический указатель?
Во первых нет смысла заморачиваться с CreationPolicy, всегда для синглтона можно сделать дефолтный конструктор.
Во вторых ваша система полетит при мульти трединге.
Предлагаю вариант на случай если мульти трединг и скорость доступа актуальны.
(код под винду)
template <typename T>
class SingletoneS
{
static T * CreateSingletone()
{
if (::InterlockedIncrement(&m_Lock) == 1)
{
_instance = new T();
}
else
WaitForSingleObject(m_lSignal,INFINITE);
Instance = ReturnInstance;
SetEvent(m_lSignal);
return Instance();
}
static T * ReturnInstance()
{
return _instance;
}
static T * _instance;
static volatile LONG m_Lock;
static HANDLE m_lSignal;
public:
static void Reset()
{
T * temp = _instance;
_instance = NULL;
ResetEvent(m_lSignal);
Instance = CreateSingletone;
delete temp;
}
static T * (__cdecl * Instance)(void) ;
};
template <typename T> T * SingletoneS<T>::_instance = NULL;
template <typename T> volatile LONG SingletoneS<T>::m_Lock = 0;
template <typename T> T * (__cdecl * SingletoneS<T>::Instance)(void) = SingletoneS<T>::CreateSingletone;
template <typename T> HANDLE SingletoneS<T>::m_lSignal = CreateEvent(NULL,NULL,false,NULL);
template <typename T> T * Singletone()
{
return SingletoneS<T>::Instance();
}
#define DefineSingletone(Class) \
private:\
friend class SingletoneS<Class>; \
Class();
Здравствуйте, ilvi, Вы писали:
I>Здравствуйте, agg, Вы писали:
agg>>Здравствуйте, встала задача написать Singleton для iPhone, посмотрел иходник из Loki и вот что получилось:
I>для ифона уже можно писать на c++?
Там получается таким образом, все что касается работы с классами платформы iPhone нужно писать на Objective C, если хочешь в Objective C использовать C++ классы, то файлам реализации ставишь расширение mm( namefile.mm ), C++ классы пишешь так же, только в коде Objective C при включении желательно использовать #import а не #include. Нужно это для того чтобы все побыстрее шевелилось, переведя просто из Objective C на C++ движок который обсчитывает всякую геометрию и трансформации координат получился реальный прирост скорости, что аж пришлось замедлять в некоторых местах
agg>Но никакие финты не помогли, такое предчувствие что я переработал и немного затупил, подскажите пожалуйста как правильно занулить статический указатель?
template<class T, template <typename T> class CreationPolicy = CreateUsingNew>
class Singleton
{
typedef typename T ObjectType;
public:
static T& Instance();
protected:
Singleton(){}
private:
static Singleton<T,CreationPolicy>* _instance;
};
template <class T,template <typename T> class CreationPolicy>
Singleton<T,CreationPolicy>* Singleton<T,CreationPolicy>::_instance;
Здравствуйте, agg, Вы писали:
agg>То есть его явно что ли ненужно писать что равно 0?
Вроде бы в С++ статические фундаментальные типы инициализируются нулями—нет?
agg>>То есть его явно что ли ненужно писать что равно 0? B>Вроде бы в С++ статические фундаментальные типы инициализируются нулями—нет?
Только не поинтеры.
Здравствуйте, tonykent, Вы писали:
T>Хм, проверил сейчас. И правда — поинтеры тоже на моей студии 2008. Интересно было бы в стандарт заглянуть.
В винде и будут, загрузчик зануляет неинициализированные данные. Но вроде встречал и в стандарте о статических данных.
I>Круто. Даже это уже хорошо. Я просто думал, что при отсутствии желания писать на Object-C остается возможность писать только на голом Си. В аппле сторе с таким си++ вставками тоже принимают?
У нас "нутро" проекта на C++ и с STL. Продаётся на AppStore.
На Objective-C необходимо (хотя и в этом не уверен) писать интерфейсные части.
Здравствуйте, встала задача написать Singleton для iPhone, посмотрел иходник из Loki и вот что получилось:
template<class T, template <class> class CreationPolicy = CreateUsingNew> class Singleton
{
typedef T ObjectType;
public:
static T& Instance();
protected:
Singleton(){}
private:
static Singleton* _instance;
};
Все отлично кроме строки инициализации указателя. Реализация находится в том же заголовке вот строка на которую ругается компилятор(GCC 4.0):
Singleton* Singleton::_instance=0; //error: expected constructor, destructor, or type conversion before '*' token
пробовал разжевать ему:
template<class T, template <class> class C>Singleton* Singleton<T, C>::_instance=0;
Но никакие финты не помогли, такое предчувствие что я переработал и немного затупил, подскажите пожалуйста как правильно занулить статический указатель?
Здравствуйте, tonykent, Вы писали:
agg>>Но никакие финты не помогли, такое предчувствие что я переработал и немного затупил, подскажите пожалуйста как правильно занулить статический указатель?
Здравствуйте, agg, Вы писали:
agg>Здравствуйте, tonykent, Вы писали:
agg>>>Но никакие финты не помогли, такое предчувствие что я переработал и немного затупил, подскажите пожалуйста как правильно занулить статический указатель?
Здравствуйте, tonykent, Вы писали:
T>Здравствуйте, agg, Вы писали:
agg>>Здравствуйте, tonykent, Вы писали:
agg>>>>Но никакие финты не помогли, такое предчувствие что я переработал и немного затупил, подскажите пожалуйста как правильно занулить статический указатель?
agg>>То есть его явно что ли ненужно писать что равно 0?
T>Надо. Я забыл. я тебе просто показал, в чем были проблемы.
Спасибо большое я уже понял что специализацю одну ненаписал
Здравствуйте, byleas, Вы писали:
B>Здравствуйте, agg, Вы писали:
agg>>То есть его явно что ли ненужно писать что равно 0? B>Вроде бы в С++ статические фундаментальные типы инициализируются нулями—нет?
Хм, проверил сейчас. И правда — поинтеры тоже на моей студии 2008. Интересно было бы в стандарт заглянуть.
Здравствуйте, tonykent, Вы писали:
T>Здравствуйте, byleas, Вы писали:
B>>Здравствуйте, agg, Вы писали:
agg>>>То есть его явно что ли ненужно писать что равно 0? B>>Вроде бы в С++ статические фундаментальные типы инициализируются нулями—нет? T>Хм, проверил сейчас. И правда — поинтеры тоже на моей студии 2008. Интересно было бы в стандарт заглянуть.
T>>Хм, проверил сейчас. И правда — поинтеры тоже на моей студии 2008. Интересно было бы в стандарт заглянуть.
PY>в debug или в release?
И там, и там. Но даже если это и позволяется стандартом — я всё-равно буду явно инициализировать.
Ну раз развелась такая дискуссия то новый вопрос. В этом классе подразумеваются стратегии создания/удаления, на данный момент у меня их 2, ни буду выдумывать что я супер гений который их придумал я их тупо скопировал из Loki, ну чуток подпилил их выглядят они вот так:
1) в куче
template <class T> struct CreateStatic
{
union MaxAlign
{
char t_[sizeof(T)];
short int shortInt_;
int int_;
long int longInt_;
float float_;
double double_;
long double longDouble_;
struct Test;
int Test::* pMember_;
int (Test::*pMemberFn_)(int);
};
static T* Create()
{
static MaxAlign staticMemory_;
return new(&staticMemory_) T; //error: no matching function for call to 'operator new(long unsigned int, CreateStatic<A>::MaxAlign*)'
}
static void Destroy(T* p)
{
p->~T();
}
};
прием для стэка на основе сегмента статической памяти.
В общем в строке с размещающем new компилятор говорит что нет соответствующей функции для вызова, пытаюсь понять это особенность моего затупления или все таки для iPhone OS так писать нельзя, подскажите кто знает?
Re[2]: Singleton руками
От:
Аноним
Дата:
25.05.09 13:34
Оценка:
Здравствуйте, agg, Вы писали:
agg>2) в стэке
встречный вопрос, а почему не подходит более простой вариант?
Здравствуйте, agg, Вы писали: agg>Там получается таким образом, все что касается работы с классами платформы iPhone нужно писать на Objective C, если хочешь в Objective C использовать C++ классы, то файлам реализации ставишь расширение mm( namefile.mm ), C++ классы пишешь так же, только в коде Objective C при включении желательно использовать #import а не #include. Нужно это для того чтобы все побыстрее шевелилось, переведя просто из Objective C на C++ движок который обсчитывает всякую геометрию и трансформации координат получился реальный прирост скорости, что аж пришлось замедлять в некоторых местах
Круто. Даже это уже хорошо. Я просто думал, что при отсутствии желания писать на Object C остается возможноссть писать только на голом Си. В аппле сторе с таким си++ вставками тоже принимают?
... << RSDN@Home 1.2.0 alpha 4 rev. 1218>>
Re[4]: offtopic
От:
Аноним
Дата:
25.05.09 18:11
Оценка:
Здравствуйте, ilvi, Вы писали: I>Круто. Даже это уже хорошо. Я просто думал, что при отсутствии желания писать на Object C остается возможноссть писать только на голом Си. В аппле сторе с таким си++ вставками тоже принимают?
Я пишу заказчикам, как они это делают я без понятия , но они довольны, наверно пускают. Кстати может быть если вам не трудно вы скинете ссылочку, в которой детально описывается процесс как размещать в эппл стори свои программы?
Здравствуйте, <Аноним>, Вы писали:
А>Я пишу заказчикам, как они это делают я без понятия , но они довольны, наверно пускают. Кстати может быть если вам не трудно вы скинете ссылочку, в которой детально описывается процесс как размещать в эппл стори свои программы?
Сам пока этим не занимался. Друзья размещали. После получения лицензии, что является отдельным квестом, они отправляли исходники в апл. Те их просматривают и говорят либо что-то переделать, либо берут сразу, либо дают отказ.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218>>
Re[3]: Singleton руками
От:
Аноним
Дата:
26.05.09 04:44
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, agg, Вы писали:
agg>>2) в стэке
А>встречный вопрос, а почему не подходит более простой вариант?
А>
Мне тоже приходила в голову такая мысль, но почему-то взял второй вариант, только у вас там небольшая ошибочка, а вот так правильно как мне кажется будет:
Здравствуйте, Аноним, Вы писали:
А>встречный вопрос, а почему не подходит более простой вариант?
А ничего, что деструктор будет вызван дважды?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, agg, Вы писали:
agg>Всем большое спасибо за участие в обсуждении, тестировал в XCODE 3.1.2, Simulator 2.2.1 и вот собственно говоря плод всех дебатов:
Мои скромные замечания.
1) Зачем нужно поле CreateStatic::t? Оно же дублирует поле Singleton::_instance?
2) В случае CreateStatic деструктор объекта позовётся дважды.
3) Так как синглетон ленивый, возможны всякие странные эффекты. Суть которых состоит в том, что мы можем создать синглетон слишком поздно (типа уже на этапе разрушения статических объектов), либо, наоборот, слишком рано, из-за чего к нему кто-то обратиться уже после разрушения объекта...
Мои скромные вопросы
1) А что делать, если мне надо два разных синглетона одного типа? Скажем две строки? Или T -- это в принципе свой хитрый, самописный класс, у которого нельзя создавать два экземпляра? Почему тогда "синглетонность" прикручивают к нему снаружи?
2) Зачем вообще выбор между политиками аллокации? Какие будут рекомендации для пользователей, какую когда выбрать?
3) Чем это лучше, чем синглетон Майерса?
4) Если уж так нужны политики, то от чего бы не сделать два разных синглетона и всё?
5) А что делать, если я хочу инициализировать синглетон не конструктором по умолчанию, а как-то ещё?
Мои скромные предложения.
Вариант 1.
Пользоваться статическими переменными и не страдать... На крайняк можно иметь конструкцию вроде:
Ну и заводить просто глобальные переменные нужных типов. Скажем extern CStaticData<std::string> logBuffer;
где-то в Cpp можно написать: CStaticData<std::string> logBuffer = "Начало зависи в лог: " + getFormattedTime + "\r\n";
Ну и везде писать потом logBuffer.Get()
Вариант 2
Если таки уж очень нужно сохранить текущую схему, то я бы конечно переписал по крайней мере это:
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, agg, Вы писали:
agg>>Всем большое спасибо за участие в обсуждении, тестировал в XCODE 3.1.2, Simulator 2.2.1 и вот собственно говоря плод всех дебатов:
E>Мои скромные замечания. E>1) Зачем нужно поле CreateStatic::t? Оно же дублирует поле Singleton::_instance? E>2) В случае CreateStatic деструктор объекта позовётся дважды. E>3) Так как синглетон ленивый, возможны всякие странные эффекты. Суть которых состоит в том, что мы можем создать синглетон слишком поздно (типа уже на этапе разрушения статических объектов), либо, наоборот, слишком рано, из-за чего к нему кто-то обратиться уже после разрушения объекта...
E>Мои скромные вопросы E>1) А что делать, если мне надо два разных синглетона одного типа? Скажем две строки? Или T -- это в принципе свой хитрый, самописный класс, у которого нельзя создавать два экземпляра? Почему тогда "синглетонность" прикручивают к нему снаружи? E>2) Зачем вообще выбор между политиками аллокации? Какие будут рекомендации для пользователей, какую когда выбрать? E>3) Чем это лучше, чем синглетон Майерса? E>4) Если уж так нужны политики, то от чего бы не сделать два разных синглетона и всё? E>5) А что делать, если я хочу инициализировать синглетон не конструктором по умолчанию, а как-то ещё?
Замечания
1) Разумно
2) CreateStatic::Destroy не доглядел, первая реализация метода Create была с использованием размещающего new, поэтому и остался вызов деструктора в методе CreateStatic::Destroy
3) У меня есть мысль как как реализовать стратегию феникс, чтобы если он уничтожен возраждался из пепла , но пока сложно, тем более я это делал чтобы это компилилось и работало для iPhone OS, для обычных операционок в том числе и для MAC OS лучше взять Loki там реально все круто с синглтоном и я всегда пользовался ей, просто для iPhone нет реализации Loki, и принцип я брал именно оттуда.
Вопросы
1)Ну я так понял возник вопрос использования вот пример:
#include"Singleton.h"class A
{
friend struct CreateStatic<A>;
A(){}
A(const A&a)
{}
A& operator=(const A&a){return *this;}
public:
int f()
{
int h=999;
return h;
}
};
typedef Singleton<A,CreateStatic> SinglA;
использовать вот так:
...
SinglA::Instance().f();
...
2) Политика аллокации нужна если к примеру у тебя на устройстве динамически создавать очень медленно, ну и гибкость она не помешает.
3) Я разве сказал что синглтон Майерса хуже, он хуже только тем что к синглтону Маерса не прикрутишь стратегию создания в куче.
4) Как угодно уважаемый делайте, но я приучаю себя делать гибко и правильно.
5) Делайте метод Initialize или что-то вроде этого.
E>Ну и заводить просто глобальные переменные нужных типов. Скажем extern CStaticData<std::string> logBuffer; E>где-то в Cpp можно написать: CStaticData<std::string> logBuffer = "Начало зависи в лог: " + getFormattedTime + "\r\n"; E>Ну и везде писать потом logBuffer.Get()
E>Вариант 2 E>Если таки уж очень нужно сохранить текущую схему, то я бы конечно переписал по крайней мере это:
Предложение по коду мне откровенно не нравится из-за своей не гибкости и полным отсутствием изящности кода, это не реализация паттерна синглтон, а просто штука способная залепить определенную дырку, но любой код имеет право на существование и это всего лишь мое мнение. Вы написали новую реализацию CreateStatic::Destroy откуда там возьмется instance непонятно, если убрать t то нужно будет убрать проверку адресов p и t что не очень хорошо.
agg>Замечания agg>3) У меня есть мысль как как реализовать стратегию феникс, чтобы если он уничтожен возраждался из пепла , но пока сложно, тем более я это делал чтобы это компилилось и работало для iPhone OS, для обычных операционок в том числе и для MAC OS лучше взять Loki там реально все круто с синглтоном и я всегда пользовался ей, просто для iPhone нет реализации Loki, и принцип я брал именно оттуда.
Зачем иметь возможность выбора стратегии ДЛЯ КАЖДОГО СИНГЛЕТОНА? Почему бы сразу для всех не выбраь и не закрепить этот выбор в шаблоне класса Singleton?
agg>использовать вот так: agg>
agg>SinglA::Instance().f();
agg>
Я про другое спрашивал. Что делать если я хочу иметь два синглетона одного типа. Например две таблицы какие-нибудь разные, но однотипные?..
agg>2) Политика аллокации нужна если к примеру у тебя на устройстве динамически создавать очень медленно, ну и гибкость она не помешает.
Ну если на устрйостве надо синглетоны создавать не динамически, а статически, то и что? Почему бы жтот выбор не далеть сразу дял всех синглетонов этого устройства? agg>3) Я разве сказал что синглтон Майерса хуже, он хуже только тем что к синглтону Маерса не прикрутишь стратегию создания в куче.
Почему? Создайшь по new И регишь в atexit...
Выбор не прикрутишь, это да. Но я не понимаю, зачем нужен выбор...
agg>5) Делайте метод Initialize или что-то вроде этого.
Э-э-э, а откуда его вызывать? И что будут делать коиенты синглетона, обратившиеся к нему до того, как я этот метод позвал?
agg>Спасибо за удачные замечания.
Всегда пожалуйста, но для спасибо тут есть кнопки
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, agg, Вы писали:
agg>Вы написали новую реализацию CreateStatic::Destroy откуда там возьмется instance непонятно, если убрать t то нужно будет убрать проверку адресов p и t что не очень хорошо.
Понял! Ну да, можно у своего же Create спросить адрес, в принципе...
1) Тут принято обращение на "ты".
2) Чем тебе t нравится больше, чем &instance? Ведь они должны быть равны в деструкторе? Зачем хранить этот адрес ещё и в отдельной переменной? Его же можно спросить у себя же?
Что касается гибкости и негибкости, то я
1) Не понимаю зачем нужна гибкость именно в этом месте. Вот гибкость в вариантах инициализации или гибкость в том, что можно иметь несколько синглетонов одного типа -- это я понимаю зачем надо. А зачем надо иметь возможность рулить стратегией аллокации синглетона -- не понимаю. Если на какой-то платформе надо хранить синглетоны так-то, то это значит что на этой платфориме надо использовать модифицированный шаблон синглетона... Может быть, если ты приведёшь юзкейс, демонстрирующий когда нужно использовать не стратегию аллокации синглетонов по умолчанию, а какую-то другую, то станет понятнее зачем нужна гибкость такого рода...
2) Ненужную гибкость считаю вредной. Так как это лишний повод ошибиться...
3) Единственная опция, в нужность которой я готов поверить -- это феникс, хотя тоже сомнительно, конечно. Ну так вот, для феникса, вроде бы, должно быть всё равно, какая там у нас стратегия аллокации...
Пересоздавай да и радуйся...
Можно, кстати, пойти ещё и по третьему пути -- аллокировать место под объект и никогда его не освобождать. Потом в этом месте создавать и разрушать объект синглетона. И сделать его возраждение опциональным...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Caracrist, Вы писали:
C>Во вторых ваша система полетит при мульти трединге.
А разве на iPhone такое бывает?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Dair, Вы писали:
D>Кстати, ObjC — отличный язык
+500!!!
Для GUI и всякого интеропа так вообще супер!!!
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Dair, Вы писали:
D>У нас "нутро" проекта на C++ и с STL. Продаётся на AppStore. D>На Objective-C необходимо (хотя и в этом не уверен) писать интерфейсные части.
D>Кстати, ObjC — отличный язык
Ясно. Это действительно радует. По поводу языка ObjC я только учусь его готовить и некоторые моменты мне пока не подуше