А где это применимо? Даже если и возникает такая ситуация, неужели настолько трудно создать интерфейс IAC и использовать такой же подход, как и в COM?
Где-то ниже уже говорили о использовании буста, для того, чтобы наложить ограничения на передаваемый в функцию объект. Если вы не хотите его за собой тянуть — dynamic_cast и assert вам в помощь.
Так а зачем это выносить в один метод? Один конкретный метод решает одну маленьку конкретную задачу. Разбейте этот метод на 2: один использует функционал А, другой — В. Если не получается — у Вас явная ошибка в проектировании.
Вообще-то, в ситуациях, подобных описанной Вами, когда есть несколько ресурсов, которые используются только совместно — по сути, они являются одним ресурсом, и для него нужен только один объект синхронизации (мютекс, критическая секция, smart lock, неважно).
Да и вообще, идея объединения ресурса и объекта синхрониазации — не лучший способ организации многопоточной системы: это лишь усложняет систему.
И еще одно замечание: паттерны конечно хорошо, но необходимо пользоваться ими в меру, без фанатизма.
Писать о пользе TDD/BDD — это сейчас модно, стильно, молодежно? Ну надоели уже. Те, кто хотел — уже все для себя решили.
Нет, я не противник TDD. Я просто считаю его таким же самым инструментом, как и все остальное и применяю его я тогда, когда это уместно.
> wchar_t* x = L«Fred»; // нарушение
> char* x = «Fred»;
Вообще-то, и то, и другое нарушение, если уж на то пошло. Модификатор const здесь просто необходим.
Тем более, однако, насколько я помню, RWLock'и в винде являются user-mode объектами синхронизации, а это значит, что не происходит переходов в режим ядра, и соответсвенно, меньше затрат.
Ну я ж говорю, что набросал на скорую руку, универсальности решения я не стемился добиться. Если передо мной стояла такая задача, то был бы совсем другой подход, и, возможно решение. Да и вообще для таких задач в плюсах есть std::list и std::reverse :).
Хорошая реализация у Рихтера, насколько я помню была. Там использовалась глобальная переменная, работа с которой велась с помощью семейства Interlocked-функий, и два мютекса или критических секции.
Ну а вообще, да, с Висты, например, есть реализованные на уровне ОС read-write локи, да и практически в каждом хорошем фрейворке они уже тоже есть. Но суть изначального вопроса в понимании принципа реализации, никто не будет заставлять писать свои велосипеды, когда уже есть хорошие реализации (в некоторых фирмах за такое и по рукам бьют :)).
Суть задания в том, чтобы не создавать новый список, а чтобы переставить элементы уже имеющегося. Пока думал над решениями задачи проскочило еще парочку вариантов, но они более требовательны по памяти и медленней по скорости:
1) Менять местами соседние эл-ты списка, что-то по типу пузырьковой сортировки. Сложность, как ни трудно догадаться O(n^2)
2) Пройтись по списку, сохранив все указатели в вектор/массив и потом снова проходясь по списку уже через вектор/массив просто подставить созраненные значения.
Еще одно небольшое замечание. Насколько я понимаю, в этом коде:
> Manager(manager).GetBonus;
Приведения типов нет вообще. Вы создали временный объект класса Manager с помощью конструктора копирования, который либо написали сами, либо за Вас его написал компилятор, а затем вызвали метод временного объекта.
Есть окно Bookmarks, с помощью которого доступны все выставленные закладки с указанием файла и номера строки, на которой была установлена закладка. Навигация с помощью данного окна удобней и наглядней, нет необходимости запоминать номера закладок, плюс ко всему есть возможность отключения закладки без её удаления.
Где-то ниже уже говорили о использовании буста, для того, чтобы наложить ограничения на передаваемый в функцию объект. Если вы не хотите его за собой тянуть — dynamic_cast и assert вам в помощь.
Это признак ошибки в проектировании, как я уже и говорил.
Да и вообще, идея объединения ресурса и объекта синхрониазации — не лучший способ организации многопоточной системы: это лишь усложняет систему.
И еще одно замечание: паттерны конечно хорошо, но необходимо пользоваться ими в меру, без фанатизма.
Нет, я не противник TDD. Я просто считаю его таким же самым инструментом, как и все остальное и применяю его я тогда, когда это уместно.
> char* x = «Fred»;
Вообще-то, и то, и другое нарушение, если уж на то пошло. Модификатор const здесь просто необходим.
Ну а вообще, да, с Висты, например, есть реализованные на уровне ОС read-write локи, да и практически в каждом хорошем фрейворке они уже тоже есть. Но суть изначального вопроса в понимании принципа реализации, никто не будет заставлять писать свои велосипеды, когда уже есть хорошие реализации (в некоторых фирмах за такое и по рукам бьют :)).
1) Менять местами соседние эл-ты списка, что-то по типу пузырьковой сортировки. Сложность, как ни трудно догадаться O(n^2)
2) Пройтись по списку, сохранив все указатели в вектор/массив и потом снова проходясь по списку уже через вектор/массив просто подставить созраненные значения.
Говорили о вкусах, закончили вкусами, да весь пост здесь вообще-то о вкусах, раз уж на то пошло :).
> Manager(manager).GetBonus;
Приведения типов нет вообще. Вы создали временный объект класса Manager с помощью конструктора копирования, который либо написали сами, либо за Вас его написал компилятор, а затем вызвали метод временного объекта.