есть чисто виртуальный класс


есть некие классы с данными


и наконец общий класс, являющийся вектором А


которому передается ссылка на базовый класс Base.

1.Так вот - как можно (и можно ли вообще) получить из классов, унаследованных от Base получить доступ к данным классов Ai и Result.
2. Внутри Result есть указатель на базовый класс Base. Но мне нужна
копия этого класса. Если создавать класс, то не понятно какой класс
(я про его наследников)

Как правильно это сделать ?

Брррррррррр,

Нихрена не понял...
кто от кого наследует..кто такой Ai, кто такой А???
Я что-то ни одного наследника Base не вижу...где переопределенная функция f()?
Какую ссылку получает твой конструктор копирования? Если можно поподробней...и где вообще обявление класса A?

, вот это каша... ПРОЕКТИРУЙ НОРМАЛЬНО, ТОГДА ТАКИХ ПРОБЛЕМ НЕ БУДЕТ!!!

class Result : std::vector <A> - так нельзя, поскольку std::vector не предназначен для этого;

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


это класс-вектор Ai



да это любой класс, унаследованный от Base. Только передается ссылка на базовый класс (я не стал писать лишнего )


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

Начнем с того что

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



реализацию в студию...что значит класс-вектор???
а получить обьект child из указателья base динамически можно с помощю dynamic_cast<child*>(base_)

покажи обявление класса A

Копию абстрактного типа можно создать так:


Для получения данных создай метод:

Для редактирования данных создай метод:


Это сообщение отредактировал(а) np9mi7 - 19.1.2006, 12:11

это значит



а откуда я знаю что это за наследник ?

хорошо - попорядку

1.есть класс с закрытыми данными PrClass, который создает внутри поток и складывает
в свою очередь данные (пусть для наглядности это будет очередь int-ов 1,2,3...)

Этих классов несколько

2. Есть класс-вектор, который содержит эти классы


3. Внутри VecClass запускается еще один поток, который обрабатывает очереди классов
PrClass. Но как их обрабатывать знает только класс ExClass (это чисто виртуальный
класс с определенным интерфейсом)


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

Но !!!
1. классы PrClass вспомагательные (у них закрыты конструкторы и деструкторы). Их может создавать только класс-вектор VecClass. Поэтому встает вопрос доступа к из
закрытым данным
2. Внутри VecClass нужно хранить копию объекта унаследованного от ExClass.
т.к. это астрактный класс, то хранить получается только указатель на базовый класс.
Но тогда как создать копию его наследника ?


Надеюсь понятно объяснил

Может было бы разумно выразить вопросс в более удобоваримом виде ?

А не проще будет просто VecClass унаследовать от ExClass и внутри определить методы обаботки (Если я правельно понял конечно)?

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

Противоречие в определении !

На мой взгляд, решение простое - отказатся от абстрактного класса ExClass.

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


но мне больше нравиться с помощью template классов

А для доступа подружи классы...

Подходит вариант?

Это сообщение отредактировал(а) azesmcar - 19.1.2006, 14:02

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



я думаю, что с Clone() все проще и нагляднее

А зачем? Чем ссылка хуже указателя в данном случае? Полиморфизм распроcтраняется не только на указатели, но и на ссылки.

Более того, можно сделать и так

И абстрактность класса здесь не причем, поскольку никакого объекта класса Base не создаем

По теме. Ставим задачу
Есть три класса A, B, C. Нужно чтобы класс A и его наследники получили доступ к закрытым члена классов B и С.
Шаг первый. Делаем класс A другом B и С, и первую задачу( класс А получил доступ к закрытым членам) выполнили. К сожалению дружественность не наследуется, поэтому
Шаг второй. Добавляем в A protected медоды, которые будут принимать в качестве параметра экземпляры классов и возвращать ссылки(указатели) на нужные нам закрытые поля. Вторая часть задачи выполнена.

терминология!

есть чисто виртуальные методы (pure virtual method).

есть абстрактные классы.

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

Это сообщение отредактировал(а) blackofe - 19.1.2006, 20:08

что-то не совсем понял

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

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

Примерно так

А вообще, если для одного класса требуется доступ к приватным членов двух другиз классов, я бы задумался над правильностью дизайна
Добавлено @ 12:29

ООП зиждится на понятиях класса и объекта, а также трех основных парадигмах - наследование, инкапсуляция, полиморфизм. В STL есть классы, на основе которых создаются объекты, есть наследование и инкапсуляция. Неужели только из-за того, что там не использованы виртуальные деструкторы, Вы отказываете ей в объектно-ориентированности?

А также есть статический полиморфизм ...

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

а если в библиотеке используются слова class и конструкции типа class A : public B {};, то это еще не делает эту библиотеку объектно-ориентированной.

цитата из dr.dobb's journal за 1995 год:

While the STL is powerful, it has its limitations, the biggest being that it is not very object oriented. Object orientation depends on data and algorithms being combined under one interface. The whole premise of the STL is at odds with this: The STL separates data and algorithms, allowing their recombination in novel and useful ways.

краткий перевод:

"STL - это круто, но не объектно-ориентировано. и хотя это не объектно-ориентировано, это все-равно круто."

если вы подписаны на ddj, то там (мартовский номер 1995 года) можно найти статью - интервью с александром степановым ("Alexander Stepanov and STL"). в ней степанов если не противопоставляет stl объектно-ориентированному программированию, то, по крайней мере, четко разделяет.

STL is an important addition to the evolution of Standard C++, not only for the rich library of container classes that it provides, but also for its insight into "generic programming," a different approach to designing and developing code.

сам степанов вот чего говорит:

Object-oriented programming aficionados think that everything is an object. When I was working on the Ada generic library, I realized that this wasn't so. There are things that are objects: Things that have state and change their state are objects. And then there are things that are not objects. A binary search is not an object. It is an algorithm. Moreover, I realized that by decomposing the component space into several orthogonal dimensions, we can reduce the number of components, and, more importantly, we can provide a conceptual framework of how to design things.

так что STL - это красиво, эффективно, но не объектно-ориентировано в строгом смысле этого слова.

За 10 лет, прошедших с 1995 года представление об ООП тоже весьма изменилось.
Например, в одной из своих книг Мейерс показывает, что в интерфейс класса входят не только его методы, но и внешние функции, предоставляющие дополнительный сервис и определенные в некотором смысле "рядом" с этим классом. В этом смысле STL можно считать библиотекой контейнеров, снабженную дополнительными сервисами в виде алгоритмов.

И где в цитате Степанова написано, что STL - не объектно-ориентированная? Там написано, что она не только объектно-ориентированная. И что generic programming - методология, которая позволяет учлучшить чистую ООП-архитектуру.
Кроме того, именно STL стирает разницу между функциями и объектами: функтор - он тебе и объект и функция одновременно. Я бы сказала, что STL пропагандирует еще большую инкапсуляцию, чем принципы раннего ООП.

Но в одном ты прав: использование слова class и наследования не делает код объектно-ориентированным. Только это не про STL.

Тупик...

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

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

Нужен опытный совет

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


Как лучше и правильнее поступить ?