Ну сделай конструктор класса DATA приватным. И если надо будет создать экземпляр класса, делай его дружественным по отношению к другому классу.
Code: class DATA { public: методы... private: DATA() { инициализация... } }; class LIST { public: LIST() { Head = new DATA(); }// как в такой ситуации быть? методы... private: DATA* Head; }; А если вот такая ситуация?
объяви класс внутри класса LIST с модификатором private. вроде должно помочь. Code: class LIST { private: class DATA { public: DATA() { } }; public: LIST() { Head = new DATA(); }// как в такой ситуации быть? private: DATA* Head; };
Я же написал постом выше. Code: class DATA { [b]friend class LIST;[/b] public: методы... private: DATA() { инициализация... } }; class LIST { public: LIST() { Head = new DATA(); }// как в такой ситуации быть? методы... private: DATA* Head; };
razb это мягко говоря через жопу =) главная трабла что по сути ты аналог синглетона делать задумал. т.е. приватить надо не только дефолтный конструктор. еще копирования и перегрузку оператора =. Что не есть очень удобно и красиво.
razb, я прочитал не отредактированный вариант твоего сообщения, когда свой написал - твой пост уже был обновлен =) Я еще не дочитал до дружественных отношений классов... Ra$cal, ща попробую.
По поводу удобства еще можно поспорить если классы очень объемные то удобней разнести по разным файлам и обьявить такую связь. Также если данный класс используется не только одним другим классом например. Я думаю не составит особого труда сделать и это )
Ra$cal, помогло, еще раз спасибо! З.Ы. я сначала сделал не совсем так как ты написал и мучался долго с ошибками, потом обратил внимание, что private объявлен раньше public. Переделал и помогло! Не думал что это может как-то повлиять З.Ы.Ы. Еще никогда у мну не было таких конструкций: Code: LIST::DATA* LIST::DATA::GetPrev() и LIST::DATA::DATA(int* aValue, char* aText, DATA* aPrev, int num) Круто)
Лучше б их по возможности и не было (делай typedef'ы) или было как можно меньше )) Код должен быть понятным с первого взгляда )
не, с классами не получится создавать альясы через namespace. как вариант можешь писать код класса DATA прямо в хидере =) ну или тайпдефы\дефайны.
Как создать программу(.exe) исли у тебя есть входной файл #include <iostream.h> int main(){ int a, b, res; char op; cout << "\nВведите 1й операнд :"; cin >> a; cout << "\nВведите знак операции : "; cin >> op cout << "\nВведите 2й операнд : "; cin >> b bool f = true; switch (op){ case '+' : res = a + b; break; case '-' : res = a - b; break; case '*' : res = a * b; break; case '/' : res = a / b; break; default : cout <<"\nНеизвестная операция"; f = false; } if (f) cout << "\nРезультат : " << res; return 0 } ---вот это ! как?
нужно работать с dll как с com объектом (в ней всего 5 функций - одна из них - DllGetClassObject). это всё конечно хорошо, но разбираться с com слишком долго. есть готовые либы\функции которыми можно загрузить такую dll и юзать её com функции?
Ra$cal, дописал я наконец хедер. Несколько дней напрягался! Посмотри, если не лень и скажи свое мнение по поводу проделанной мною работы ->хедер<-
на первый онный взгляд все вполне норм. тока для начала не советую загромождать интерфейс класса методами перегружеными, которые не очень востребованы. в твоем случае это int*, ибо проще при вызове для таких мест сделать *value. DATA* Find(int* node_num)const;//Искать узел с заданным номером этот метод убрать под private. и старайся не делать меотдов с int* параметрами, если только это не массивы(это относится ко всем типам, особенно встроенным). ибо просто так числа по указателю передают если это массив или если туда возвращается значнеие. в твоем случае не понятно. если параметр только для чтения - обязательно дополняй его словом const. чтобы пользователь метода четко знал, что метод не изменит эту переменную. правда это обычно юзают для ссылок на объекты классов, чтобы избегать лишних созданий копий. но это потом поймешь =) зы: не юзай укаазтели в членах данных класса без острой необходимости. иначе будут проблемы с конструкторами копирования. если не переопределишь - по умолчанию конструктор просто копирует поля. в твоем случае создается 2 объекта DATA, поля в которых указывают на одинаковую память. в итоге если один удалит значение - во втором объекте будет неверное значение считываться. и заипешься вычислять эту багу... старайся меньше юзать указателей. это не самая сильная сторона с++ =)
Тут немного не понял что ты имеешь ввиду Это да, я просто в конце доделал другой поиск с показом а про этот забыл ммм, а указатель разве не меньше памяти требует, если он только передает в другой метод адрес, вместо создания нового инта? Убрал все int* параметры, и оставил их простыми интами. Я обычно для проверки делаю так: Code: DATA(DATA&) { cout << "copy constructor...\n"; } Таким образом проверяю, не вызывается ли конструктор копировщик. Когда его вижу - значит переделываю то что вызывает его. На этот раз не видел, потому и думал что все в порядке. А где именно он вызывается? Я ж вроде везде только адреса передаю и присваиваю их указателям и контролирую чтоб не удалилось значение. А методы, в которых я использую - не возвращают ничего, за исключением возврата тех же указателей на предидущие и следующие узлы и поиска, который так же указатель возвращает... Мне просто помнятся слова нашего препода, что если освоить работу с указателями и списками - дальше проблем не будет и что указатели - одно из мощнейших средств с++) Потому и юзал их) З.Ы. нужно в подписи фразу "Ra$cal, спасибо большое еще раз" вставить
При передачи параметров по значению они копируются в стек, в случае с встроенными типами это не так уж критично, указатели стоит использовать при передачи данных больших обьемов (массивы, обьекты (хотя тут лучше ссылки) и т.д.), необходимости возвратить больше одного значения из ф-ции.
мощные - да. но все надо в меру =) научиться ты научился, теперь тренируйся их разумно использовать =) фишка в том что указатель на инт и инт занимают по 4 байта на 32 битных машинах. так что никакого выигрыша на встроенных типах. как razb написал это выгодно с объектами, конструктор которых ощутим. например передавать вектора из 10 000 элементов разумнее по ссылке(тот же указатель, только вместо -> пишешь . что гораздо удобнее. читани главу про ссылки, они удобнее указателей =) это правильно =)