Анимучан ★ Котинг

#3799, 21 апреля 2010 в 11:28

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

#3807 (>>3799), 21 апреля 2010 в 14:01

Чего ты именно хочешь? Приведи конкретный пример.
А ещё сюда скоро набегут плюсоненавистники.

#20676 (>>3807), 13 февраля 2012 в 15:27

йцйцйц

#3816 (>>3799), 21 апреля 2010 в 15:02

Паттерн называется Singleton.

class CSingleton {
public:
  static CSingleton& Instance()
  {
    static CSingleton self;
    return self;
  }
private:
  CSingleton() {}                           // Private constructor
  ~CSingleton() {}
  CSingleton(const CSingleton&);            // Prevent copy-construction
  CSingleton& operator=(const CSingleton&); // Prevent assignment
};

#20678 (>>3816), 13 февраля 2012 в 22:39

Кстати, как сделать хороший Singleton, описывается у Александреску и потом все сведено в библиотеку man Loki.

#3817 (>>3816), 21 апреля 2010 в 15:04

Получаешь экземпляр класса как CSingleton::Instance().
(Этот код НЕ thread-safe)

#3865 (>>3799), 22 апреля 2010 в 13:56

Скажите, плюсоводы, а чтобы более-менее разбираться в паттернах, это нужно от корки до корки прочитать "Паттерны проектирования"? Или есть какие-нибудь статьи, в которых всё расписано просто и на пальцах?

#3873 (>>3865), 22 апреля 2010 в 15:06

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

* http://habrahabr.ru/blogs/complete_code/

#3877 (>>3873), 22 апреля 2010 в 15:34

Нет, понятное дело, что писать паттерны, развешивать везде многоуровневые иерархии и, грубо говоря, деревьями заслонять лес, не есть хорошо и даже есть плохо. Но прокачать этот навык стоит хотя бы для того, чтобы понимать, что имеется в виду, когда небрежно пишут "а вот эту хуйню мы реализуем с помощью паттерна Итератор и больше не будем на неё отвлекаться ".
Вот, кстати, взялся наконец-то Страуструповский С++ читать. Хорошо читается, зараза.

#3885 (>>3877), 22 апреля 2010 в 16:44

Джеффа Элджера «C++» еще прочти, эпичная книга. Не такое насилие мозга как Александреску, очень умно и по делу.

#3960 (>>3885), 22 апреля 2010 в 21:06

>насилие мозга как Александреску
Александреску, кстати, тоже легко и интересно читается. Просто он использует язык нестандартным и неоднозначным образом, потому и идет с трудом. Чтобы получать удовольствие от необычной шаблонной магии, нужно уметь обращаться с шаблонами чуть сложнее, чем std::vector<int>, тогда изучение модерн цпп дизайна будет проходить модно, весело и спортивно, я гарантирую это.

#3985 (>>3960), 23 апреля 2010 в 01:08

Да я читал. Спать потом не мог.
Жаль, что на практике все это волшебство не используется почти совсем.

#3906 (>>3885), 22 апреля 2010 в 16:55

Спасибо, анон, скачал. После первого прочтения Страуструпа возьмусь за Элджера.

#4021 (>>3873), 23 апреля 2010 в 12:32

Самыми полезными книжки по плюсам, которые я читал, были Effective STL Майерса и Exceptional CPP Саттера. Они — про реальные задачи, которые встречаются тут и там, в отличие от дикой эзотерики Александреску, при жизни перенесшегося в эфир. Рикаминдую, в общем.

К тому же, Саттер похож на Бората.

#3875 (>>3873), 22 апреля 2010 в 15:22

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

#4019 (>>3875), 23 апреля 2010 в 12:18

А еще можно коучем успеха стать, например.
Или тренинги по пикапу проводить.

#4025 (>>4019), 23 апреля 2010 в 12:58

С применением паттернов проектирования? Тренинги по пикапу? Неплохая идея.

#4030 (>>4025), 23 апреля 2010 в 13:19

Барышни есть разные. Иная, услышав, что ты осилил, к примеру, Александреску и в проектах вовсю обмазываешься паттернами - сразу раздвинет ноги. Да-да.

#4038 (>>4030), 23 апреля 2010 в 13:39

Алёна C++, объект оголтелого фапа в геймдевелоперском сообществе.

Правда, это старая фоточка, щас Алёнушка стала жирная и некрасивая.

#4034 (>>4030), 23 апреля 2010 в 13:29

Не рекомендую такую барышню :3

#4243 (>>3799), 25 апреля 2010 в 17:14

Все, я больше не могу с ним воевать.
loader.h:

//инклуд всяких стандартов
class Loader
{
    public:
        static Loader loader;
        SDL_Surface* LoadImage( std::string );

        template< class T >
        bool LoadConfig( std::string, vector< T>* );
};

loader.cpp:

include loader.h
Loader Loader::loader;
//blahblah
template< class T >
bool Loader::LoadConfig( std::string filename, vector< T > *pvec )
{
    return true; //просто затычка.
}

another.cpp

void somefunction(){
    vector<SomeStruct> pvec;
    Loader::loader.LoadConfig( "somestring", &pvec );
}

another.cpp:3: undefined reference to `bool Loader::LoadConfig<SomeStruct>(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::vector<SomeStruct, std::allocator<SomeStruct> >*)'
collect2: выполнение ld завершилось с кодом возврата 1

Анон, я же делаю какую-то мелкую глупую ошибку? Где она?

#4260 (>>4243), 25 апреля 2010 в 19:06

Линкер не может найти тело LoadConfig.
Перенеси весь код твоего шаблона в заголовочный файл. И если что, выкладывай код ошибки, а не её описание.

#4267 (>>4260), 25 апреля 2010 в 19:59

И правда. Только как теперь быть? В эту функцию нужно кучу всего поместить. писать все в заголовке? Вдобавок, если в теле функции появляется хотя бы одна скобка, то компилятор сходит с ума и начинает ругаться на ) в заголовке функции, а если оно еще и в теле, то вообще неожиданные ошибки возникают, типа

main.cpp:100: ошибка: недопустимая декларация элемента-функции ‘Loader::Main::MouseMoved’ внутри ‘Loader’

Код ошибки это make: *** [Projectname] Ошибка 1?
Кроме этого еще говорит верхнюю функцию, в которой произошел фейл. больше ничего дельного не говорит. Может у меня какой-то неправильный g++?

#4290 (>>4267), 25 апреля 2010 в 22:33

Можно показать шаблону, с чем он будет работать.
.cpp:
bool Loader<SomeStruct>::LoadConfig( std::string filename, vector< T > *pvec )
Только если будешь использовать что-то кроме SomeStruct, ты должен будешь это тоже добавить в .цпп

>>Код ошибки это make: *** [Projectname] Ошибка 1?
Сорри, я думал ты со студией работаешь.

#4295 (>>4290), 25 апреля 2010 в 22:43

Зачем тогда шаблон, если все равно придется писать 9000 функций под каждый структ? Чтобы сэкономить 3 строки на вызовах?

#4303 (>>4295), 25 апреля 2010 в 23:33

Все нормальные разработчики реализуют шаблоны в заголовочных файлах.
Тогда можно будет и inline заюзать
>>Чтобы сэкономить 3 строки на вызовах?
Использование шаблонов не сокращает объём генерируемого компилятором кода.

#4346 (>>4303), 26 апреля 2010 в 13:06

>Использование шаблонов не сокращает объём генерируемого компилятором кода.
Зато позволяет разработчику писать код других мест, а не заниматься нажиманием ctrl+c ctrl+v
Думаю все-таки отказаться здесь от шаблонов и банально написать 9000 одинаковых функций. Количество разных типов все равно планирую не очень большое

#4348 (>>4346), 26 апреля 2010 в 13:29

Тогда есть смысл заюзать ООП.
Сделать интерфейс Loader и интерфейс SomeStruct, и от них плясать.

#4352 (>>4348), 26 апреля 2010 в 13:41

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

#4637 (>>4352), 29 апреля 2010 в 18:13

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

Алсо, луа — язык не для людей, но это к теме не относится, извините, не удержался.

#4643 (>>4637), 29 апреля 2010 в 18:49

Я сделал все на няшном ямле, и все даже уже рабоает. Правда парсятся пока только строки, и решение тяжеловато, но все в 2,5 функции.

#4663 (>>4643), 29 апреля 2010 в 21:23

Ямл малаца, одобряю.
>Правда парсятся пока только строки
>пока
Ты сам писал парсер штоле? Но зачем?

А что ты вообще сочиняешь там?

#4694 (>>4663), 30 апреля 2010 в 08:03

Нет, ямл-цпп приделал. Вот только он по дефолту работает очень статично, я пытаюсь добавить динамики.

#4672 (>>4663), 29 апреля 2010 в 22:12

Игрушку по юккурям же. Там внизу >>4288 исходники.

#4356 (>>4352), 26 апреля 2010 в 15:06

Конфиги на Lua, открытое API и пусть пользователь сам ебётся, как хочет, лол.

#4360 (>>4356), 26 апреля 2010 в 15:52

Именно.

#4268 (>>4267), 25 апреля 2010 в 20:01

>а если оно еще и в теле
Если функция распологается в хеадерах. Совсем не соображаю что пишу уже.

#4245 (>>4243), 25 апреля 2010 в 17:42

Попробуй явно указать специализацию функции.

Loader::loader.LoadConfig<SomeStruct>("", &pvec);

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

#4250 (>>4245), 25 апреля 2010 в 18:10

Не помогает. В общем, суть такова:
Есть разные конфиги, под каждый свой структ. another создает вектор структов одного типа и отправляется в loader, где вектор наполняется распарсенными конфигами одного типа. Чтобы не писать по функции на каждый тип конфига пытаюсь заменить это шаблонами.

#4258 (>>4250), 25 апреля 2010 в 18:59

А запилить исходники?

#4266 (>>4258), 25 апреля 2010 в 19:30

Ох, там много, а коммитить нерабочую версию не хочется.
http://paste2.org/p/793600. Как-то так. Там 5 файлов. Вызывается все это добро: Config::conf.LoadEntities();

#4277 (>>4266), 25 апреля 2010 в 21:51

Что-то мне пришло в голову. Покажи, как ты собираешь проект; возможно, ты делаешь это неправильно.

#4288 (>>4277), 25 апреля 2010 в 22:31

http://svn.xp-dev.com/svn/Yukkuri/branches/cpp/
Мейкфайл + ямл-мейкфайл ниже.

#5086 (>>3799), 5 мая 2010 в 21:46

В какой-то книжке вычитал, что vector<ClassName> при дбавлении элементов и отсуствии места в векторе будет при расширении вызывать конструктор и деструктор ClassName. Т.е. если у меня есть вектор с 10 объектами класса, и в одном из объектов я поменял какое-то свойство, то при добавлении еще n объектов в вектор, я рискую потерять все изменения предыдущих объектов?
Чисто теоретический интерес, естественно, что лучше использовать vector<ClassName*>.

#5109 (>>5086), 6 мая 2010 в 07:32

Странная какая-то книжка.
>конструктор и деструктор ClassName
Нет такого не происходит.
>естественно, что лучше использовать vector<ClassName*>
Плохая идея, лол. При перераспределении памяти может оказаться, что твои указатели указывают на произвольные места в памяти. (Страуструп, Язык программирования С++, §16.3.8).
Вообще использовать vector не как статический массив мысль плохая. ADS для кого придумали?
Купи себе Страуструпа и всегда держи под рукой.

#6787 (>>5109), 9 июня 2010 в 19:32

Вообще на плюсах писать мысль плохая.

#6789 (>>6787), 9 июня 2010 в 19:43

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

#20689 (>>6789), 20 февраля 2012 в 12:48

какой другой интерпитируемый язык может?

#20693 (>>20689), 20 февраля 2012 в 14:37

Perl.

#6834 (>>6789), 9 июня 2010 в 21:33

Haskell to the rescue!
trollface.jpg

#5451 (>>5109), 13 мая 2010 в 14:13

>Нет такого не происходит.
Нет, происходит. При наличии в ClassName нормальных копи-кторов ничего никуда не потеряется же. Другое дело, что это может оказаться медленным дохуя.
>При перераспределении памяти
Что такое перераспределение памяти и куда денутся мои данные, случись оно?
Статический массив - это ClassName a[N]; зачем здесь вектор?

#6753 (>>3799), 9 июня 2010 в 17:05

А я вот задумался, что лучше:
pair< int, int> twoint или int toint[2]. По идее статический массив лучше. Или пару лучше использовать, только на разнотипных значениях?

#6758 (>>6753), 9 июня 2010 в 17:58

Массив лучше, потому что проще.