class Interface
{
public:
virtual void func1() = 0;
virtual void func2() = 0;
};
Interface* getObject();
Проблемы с наследованием класса
Здравствуйте.
Я хочу создать класс "строка", пытаюсь наследовать ее от стандартного класса string.
class MyString : public std::string
{
public:
};
пока не добвляю никаких (которые мне нужны) дополнительных методов и данных, потом уже в программе пишу:
MyString str;
str = "Hello World!!!";
Компилятор останавливается на последней строке с ошибой "e:\projects\app1\winmain.cpp(49): error C2679: binary '=' : no operator found which takes a right-hand operand of type 'char [15]' (or there is no acceptable conversion)"
но если написать
MyString str;
str += "Hello World!!!";
то все компилится и работает.
Как избавиться от этой ошибки? И почему она вылазиет?
Я хочу создать класс "строка", пытаюсь наследовать ее от стандартного класса string.
class MyString : public std::string
{
public:
};
пока не добвляю никаких (которые мне нужны) дополнительных методов и данных, потом уже в программе пишу:
MyString str;
str = "Hello World!!!";
Компилятор останавливается на последней строке с ошибой "e:\projects\app1\winmain.cpp(49): error C2679: binary '=' : no operator found which takes a right-hand operand of type 'char [15]' (or there is no acceptable conversion)"
но если написать
MyString str;
str += "Hello World!!!";
то все компилится и работает.
Как избавиться от этой ошибки? И почему она вылазиет?
Цитата:
Originally posted by HEvgA
Я хочу создать класс "строка", пытаюсь наследовать ее от стандартного класса string.
Я хочу создать класс "строка", пытаюсь наследовать ее от стандартного класса string.
На сколько мне помнится, стандарт не рекомендует, а может и запрещает наследоваться от std::string.
Найду пункт стандарта, приведу.
Цитата:
Originally posted by HEvgA
Компилятор останавливается на последней строке с ошибой "e:\projects\app1\winmain.cpp(49): error C2679: binary '=' : no operator found which takes a right-hand operand of type 'char [15]' (or there is no acceptable conversion)"
Как избавиться от этой ошибки? И почему она вылазиет?
Компилятор останавливается на последней строке с ошибой "e:\projects\app1\winmain.cpp(49): error C2679: binary '=' : no operator found which takes a right-hand operand of type 'char [15]' (or there is no acceptable conversion)"
Как избавиться от этой ошибки? И почему она вылазиет?
Оператор присваивания (assignment operator) является специальным методом-членом, который не наследуется. См. стандарт:
http://www.csci.csusb.edu/dick/c++std/cd2/special.html#special
Избавится можно определением оператора в производном классе.
Цитата:
Originally posted by Green
На сколько мне помнится, стандарт не рекомендует, а может и запрещает наследоваться от std::string.
На сколько мне помнится, стандарт не рекомендует, а может и запрещает наследоваться от std::string.
Ужас... :))) это я по поводу наследования... и кто эти библиотеки проектирует... и им еще за это даже деньги платят... ужас однозначно :)))).... за такое проектирование в Сибирь надо отправлять снег убирать....
Цитата:
Originally posted by PitxBull
Ужас... :))) это я по поводу наследования... и кто эти библиотеки проектирует... и им еще за это даже деньги платят... ужас однозначно :)))).... за такое проектирование в Сибирь надо отправлять снег убирать....
Ужас... :))) это я по поводу наследования... и кто эти библиотеки проектирует... и им еще за это даже деньги платят... ужас однозначно :)))).... за такое проектирование в Сибирь надо отправлять снег убирать....
Не стоит так кипятится... :)
На самом деле basic_string (как и многие др.классы STL) не имеет виртуальных членов, в т.ч. виртуального деструктора.
Почему так, думаю, можно найти если поискать. Во всяком случае у авторов стандарта (не библиотеки и не различных её реализаций) были на то основания. Например, забота об оперативной памяти и т.п.
Ну а т.к. нет виртуальных методов, то нельзя наследовать интерфейс. Не вижу проблем наследовать реализацию, но Страуструп говорит, что подобные типы STL не предназначены для наследования вовсе. Этому наверное есть основательное объяснение, но его надо поискать.
Цитата:
Originally posted by Green
Не стоит так кипятится... :)
На самом деле basic_string (как и многие др.классы STL) не имеет виртуальных членов, в т.ч. виртуального деструктора.
Почему так, думаю, можно найти если поискать. Во всяком случае у авторов стандарта (не библиотеки и не различных её реализаций) были на то основания. Например, забота об оперативной памяти и т.п.
Ну а т.к. нет виртуальных методов, то нельзя наследовать интерфейс. Не вижу проблем наследовать реализацию, но Страуструп говорит, что подобные типы STL не предназначены для наследования вовсе. Этому наверное есть основательное объяснение, но его надо поискать.
Не стоит так кипятится... :)
На самом деле basic_string (как и многие др.классы STL) не имеет виртуальных членов, в т.ч. виртуального деструктора.
Почему так, думаю, можно найти если поискать. Во всяком случае у авторов стандарта (не библиотеки и не различных её реализаций) были на то основания. Например, забота об оперативной памяти и т.п.
Ну а т.к. нет виртуальных методов, то нельзя наследовать интерфейс. Не вижу проблем наследовать реализацию, но Страуструп говорит, что подобные типы STL не предназначены для наследования вовсе. Этому наверное есть основательное объяснение, но его надо поискать.
Да, мне кажется корень проблемы в конфликте (необходимости проектирования концептуально чистого языка высокого уровня) с (необходимостью его эффективной реализации на существующих аппаратных средствах).
Цитата:
Originally posted by Green
Не стоит так кипятится... :)
На самом деле basic_string (как и многие др.классы STL) не имеет виртуальных членов, в т.ч. виртуального деструктора.
Не стоит так кипятится... :)
На самом деле basic_string (как и многие др.классы STL) не имеет виртуальных членов, в т.ч. виртуального деструктора.
Мне кажется что все открытые методы класса должны быть виртуальными ( это я вообще про все классы ) иначе нет смысла их вообще выделять в класс. Ну эт уже концепция другого языка ;). Ну а STL по всей видимости проектировался не как расширяемая библиотека.... вот оказывается и у шаблонов есть недостатки ;) .... елки чуть Страустрапа в Сибирь не отправили.....)))
Цитата:
Originally posted by PitxBull
вот оказывается и у шаблонов есть недостатки ;) .... елки чуть Страустрапа в Сибирь не отправили.....)))
вот оказывается и у шаблонов есть недостатки ;) .... елки чуть Страустрапа в Сибирь не отправили.....)))
Гыг! Наследование - повторное использование кода, шаблоны - повторное использование исходников. #define-#include в объектной оболочке, не более.
Цитата:
Originally posted by PitxBull
Мне кажется что все открытые методы класса должны быть виртуальными ( это я вообще про все классы ) иначе нет смысла их вообще выделять в класс. Ну эт уже концепция другого языка ;).
Мне кажется что все открытые методы класса должны быть виртуальными ( это я вообще про все классы ) иначе нет смысла их вообще выделять в класс. Ну эт уже концепция другого языка ;).
Ну это не концепция определенного языка, это скорее частный вывод из принципа Парнаса.
Теоретически правильнее всего для "чистого ООП" создавать интерфейс (т.е. чисто абстрактный класс), а реализацию наследовать от него, при этом извне общаться только через этот интерфейс и не иметь вообще никакой информации о реализации. А собственно объекты создавать через фабрики.
Т.е. всё что видно на стороне пользователя нашей системы классов это
Код:
и всё... :)
Цитата:
Originally posted by PitxBull
вот оказывается и у шаблонов есть недостатки ;)
вот оказывается и у шаблонов есть недостатки ;)
Ну не в шаблонах дело...
Да и не в библиотеке, а в целях её создания и применения.
Цитата:
Originally posted by Freeman
Гыг! Наследование - повторное использование кода, шаблоны - повторное использование исходников. #define-#include в объектной оболочке, не более.
Гыг! Наследование - повторное использование кода, шаблоны - повторное использование исходников. #define-#include в объектной оболочке, не более.
Два в корне неверных суждения.
Наследование, как посторное использование кода, называется наследованием реализации. А ещё есть и наследование интерфейса, которое применяется в ООП значительно чаще.
Шаблоны - это не макросы, а значительно более глубокая концепция.
Цитата:
Originally posted by Green
Наследование, как посторное использование кода, называется наследованием реализации. А ещё есть и наследование интерфейса, которое применяется в ООП значительно чаще.
Наследование, как посторное использование кода, называется наследованием реализации. А ещё есть и наследование интерфейса, которое применяется в ООП значительно чаще.
Разумеется. Только в Плюсах такого понятия-то, как интерфейсы, нет.
Цитата:
Шаблоны - это не макросы, а значительно более глубокая концепция.
И в чем глубина? Если судить по практике, ни в одном языке, кроме Плюсов, шаблонов нет. Сишное решение сишных проблем?
Цитата:
Originally posted by Freeman
Разумеется. Только в Плюсах такого понятия-то, как интерфейсы, нет.
Разумеется. Только в Плюсах такого понятия-то, как интерфейсы, нет.
М-да... Ты совершенно неправ. Обратись к теории ООП.
Цитата:
Originally posted by Freeman
И в чем глубина?
И в чем глубина?
Я запарюсь различия приводить.
Поэтому назову лишь одно обобщенное - типизированность.
Цитата:
Originally posted by Freeman
Если судить по практике, ни в одном языке, кроме Плюсов, шаблонов нет. Сишное решение сишных проблем?
Если судить по практике, ни в одном языке, кроме Плюсов, шаблонов нет. Сишное решение сишных проблем?
А ты сможешь привести язык аналог С++ ?
Паскль, питон и т.п. - это обероны, они совнершенно др. концепции.
Цитата:
Originally posted by Green
Ты совершенно неправ. Обратись к теории ООП.
Ты совершенно неправ. Обратись к теории ООП.
Согласись - теория ООП в классическом виде и Плюсы - две большие разницы. А мы вроде пока про Плюсы речь ведем.
Цитата:
Поэтому назову лишь одно обобщенное - типизированность.
А, ну да. Плюсы вроде объявлены строго типизированным языком. Но это только одно решение полной типизации.
Цитата:
А ты сможешь привести язык аналог С++ ?
Ха-ха-ха! По-моему, и одного чуда достаточно. :D
Короче, вышло, что шаблоны - сишное решение сишных проблем. Это зло, но это Си, и без него никак. :D
Цитата:
Originally posted by Freeman
Согласись - теория ООП в классическом виде и Плюсы - две большие разницы. А мы вроде пока про Плюсы речь ведем.
Согласись - теория ООП в классическом виде и Плюсы - две большие разницы. А мы вроде пока про Плюсы речь ведем.
В плюсах, как и везде, все публичные члены - это интерфейс, а все закрытое - это реализация.
Если говорить об интерфейсах а-ля Java и т.п., то в плюсах и это реализуемо с помощью чисто абстрактных классов (см. пример выше).
IMHO Interface в Java - это аналог чисто абстрактного класса с С++.
Цитата:
Originally posted by Freeman
Короче, вышло, что шаблоны - сишное решение сишных проблем. Это зло, но это Си, и без него никак. :D
Короче, вышло, что шаблоны - сишное решение сишных проблем. Это зло, но это Си, и без него никак. :D
Я бы не сказал, что шаблоны - это зло.
IMHO очень даже приятная фича.
Кроме того я слышал о задумках внедрения шаблонов, как в Java, так и в C#.
Так что шаблоны в С++ - это "первая ласточка", надо же кому то было начинать.
Цитата:
Originally posted by Green
IMHO Interface в Java - это аналог чисто абстрактного класса с С++.
IMHO Interface в Java - это аналог чисто абстрактного класса с С++.
Если не может иметь полей данных - аналог. Хотя... Навскидку не помню, но неспроста его "чисто абстрактным классом" обозвали.
Цитата:
Кроме того я слышал о задумках внедрения шаблонов, как в Java, так и в C#.
Так что шаблоны в С++ - это "первая ласточка", надо же кому то было начинать.
Так что шаблоны в С++ - это "первая ласточка", надо же кому то было начинать.
А вот тут совершенно несогласен. Шаблоны будут в .NET 2.0. Но по большому счету, .NET-у они пятая нога. Вроде дефрагментаторов под Linux - щоб було. Мол, есть под Винду - пусть будут и под Линукс - надо же на чем-то бабосы рубить.
Вообще, .NET-у сильно не повезло. Технология это очень хорошая, стандарт - просто пальчики оближешь, но на сегодняшний день ни одной правильной реализации .NET нет. Ну, а "версия 2" от Майкрософт - дань моде и конъюктурщина.
Цитата:
Originally posted by Freeman
Если не может иметь полей данных - аналог. Хотя... Навскидку не помню, но неспроста его "чисто абстрактным классом" обозвали.
Если не может иметь полей данных - аналог. Хотя... Навскидку не помню, но неспроста его "чисто абстрактным классом" обозвали.
Именно поэтому "чисто абстрактным" и назвали, что никакой реализации нет, только интерфейс.
Цитата:
Originally posted by Freeman
А вот тут совершенно несогласен. Шаблоны будут в .NET 2.0. Но по большому счету, .NET-у они пятая нога. Вроде дефрагментаторов под Linux - щоб було. Мол, есть под Винду - пусть будут и под Линукс - надо же на чем-то бабосы рубить.
А вот тут совершенно несогласен. Шаблоны будут в .NET 2.0. Но по большому счету, .NET-у они пятая нога. Вроде дефрагментаторов под Linux - щоб було. Мол, есть под Винду - пусть будут и под Линукс - надо же на чем-то бабосы рубить.
Ну это уже война религий... :)
Лично я за шаблоны ибо юзаю...
Цитата:
Originally posted by Green
Ну это не концепция определенного языка, это скорее частный вывод из принципа Парнаса.
Теоретически правильнее всего для "чистого ООП" создавать интерфейс (т.е. чисто абстрактный класс), а реализацию наследовать от него, при этом извне общаться только через этот интерфейс и не иметь вообще никакой информации о реализации. А собственно объекты создавать через фабрики.
Т.е. всё что видно на стороне пользователя нашей системы классов это
и всё... :)
Ну это не концепция определенного языка, это скорее частный вывод из принципа Парнаса.
Теоретически правильнее всего для "чистого ООП" создавать интерфейс (т.е. чисто абстрактный класс), а реализацию наследовать от него, при этом извне общаться только через этот интерфейс и не иметь вообще никакой информации о реализации. А собственно объекты создавать через фабрики.
Т.е. всё что видно на стороне пользователя нашей системы классов это
Код:
class Interface
{
public:
virtual void func1() = 0;
virtual void func2() = 0;
};
Interface* getObject();
{
public:
virtual void func1() = 0;
virtual void func2() = 0;
};
Interface* getObject();
и всё... :)
Собственно это я и хотел сказать. Вот если бы еще понять почему... Как сказал Ньютон : я могу сказать что будет, но не могу сказать почему. ;) Выход на мета-уровень очевидно представляет затруднение ;) Вот интересно а он вообще есть ? :)))А насчет другого языка... ;)
Цитата:
Originally posted by Green
Ну не в шаблонах дело...
Да и не в библиотеке, а в целях её создания и применения.
Ну не в шаблонах дело...
Да и не в библиотеке, а в целях её создания и применения.
Да цели могут разными но принципы правильного проектирования (если не сказать идеального) вообщем то по побольшому счету одни. Ну ограничитель очевиден : язык, который определяет о чем мы можем думать ( Страуструп кажись сказал )... избыточная сложность языка порождает избыточную сложность мышления... здесь уже можно привести Эйнштейна но как нить в другой раз... Но именно это несоответвие концепции а также уже упомянутуя избыточная сложность порождают подобные вопросы у новичков ( и не только ;) ) ... на самом деле все гораздо проще.
Цитата:
Originally posted by Freeman
Гыг! Наследование - повторное использование кода, шаблоны - повторное использование исходников. #define-#include в объектной оболочке, не более.
Гыг! Наследование - повторное использование кода, шаблоны - повторное использование исходников. #define-#include в объектной оболочке, не более.
Дык... извиняюсь за глупый но абсолютно логичный вопрос : чем в данном контексте код отличается от исходников ? :)))))) опять помехи наводите ?
Цитата:
Originally posted by PitxBull
Выход на мета-уровень очевидно представляет затруднение ;) Вот интересно а он вообще есть ? :)))А насчет другого языка... ;)
Выход на мета-уровень очевидно представляет затруднение ;) Вот интересно а он вообще есть ? :)))А насчет другого языка... ;)
Ну я не вижу затруднений в выходе на этот мета-уровень.
В любом случае выход всегда идет с нижних этажей.
Цитата:
Originally posted by PitxBull
Но именно это несоответвие концепции а также уже упомянутуя избыточная сложность порождают подобные вопросы у новичков ( и не только ;) ) ... на самом деле все гораздо проще.
Но именно это несоответвие концепции а также уже упомянутуя избыточная сложность порождают подобные вопросы у новичков ( и не только ;) ) ... на самом деле все гораздо проще.
Вспомни, кто пользуется простыми системами, которые может использовать каждый дурак. ;)
А сложность обычно связана с обилием вариантов выбора, а не со сложность самой системы, предоставляющей этот выбор.
Простейший пример: 32 белых клетки, 32 черных, 6 видов фигур 2х цветов, а народ парится, пишет, решает уже не одну тысячу лет.
Цитата:
Originally posted by Green
Вспомни, кто пользуется простыми системами, которые может использовать каждый дурак. ;)
Вспомни, кто пользуется простыми системами, которые может использовать каждый дурак. ;)
Правильный пример простой в данном контексте системы - реляционная СУБД, полностью управляемая SQL.
Цитата:
Простейший пример: 32 белых клетки, 32 черных, 6 видов фигур 2х цветов, а народ парится, пишет, решает уже не одну тысячу лет.
Гадом буду, но это не про Плюсы. Сколько страниц описание его стандарта занимает?
Цитата:
Originally posted by PitxBull
Дык... извиняюсь за глупый но абсолютно логичный вопрос : чем в данном контексте код отличается от исходников ? :)))))) опять помехи наводите ?
Дык... извиняюсь за глупый но абсолютно логичный вопрос : чем в данном контексте код отличается от исходников ? :)))))) опять помехи наводите ?
Код в данном контексте - результат компиляции.
Цитата:
Originally posted by Green
Ну я не вижу затруднений в выходе на этот мета-уровень.
В любом случае выход всегда идет с нижних этажей.
Вспомни, кто пользуется простыми системами, которые может использовать каждый дурак. ;)
Ну я не вижу затруднений в выходе на этот мета-уровень.
В любом случае выход всегда идет с нижних этажей.
Вспомни, кто пользуется простыми системами, которые может использовать каждый дурак. ;)
Вот теперь по всем правилам ведения боя бросаем в бой резерв стоящий за кустами ( прям как в Куликовской битве ) ( древнее зло жаждущее перерождения ? ;) ) : Как сказал Эйнштейн : в объяснении всех природных процессов должно быть простое объяснение.... надеюсь с Эйнштейном спорить не будешь ? :D :D :D
Цитата:
Originally posted by Green
А сложность обычно связана с обилием вариантов выбора, а не со сложность самой системы, предоставляющей этот выбор.
Простейший пример: 32 белых клетки, 32 черных, 6 видов фигур 2х цветов, а народ парится, пишет, решает уже не одну тысячу лет.
А сложность обычно связана с обилием вариантов выбора, а не со сложность самой системы, предоставляющей этот выбор.
Простейший пример: 32 белых клетки, 32 черных, 6 видов фигур 2х цветов, а народ парится, пишет, решает уже не одну тысячу лет.
Вариантов много..... га га га .... на эту тему как то хорошо выразился Фишер (перефразировка): правильных вариантов(приносящих победу) не больше нескольких десятков.
Цитата:
Originally posted by Freeman
Код в данном контексте - результат компиляции.
Код в данном контексте - результат компиляции.
Хмс.... спорное утверждение .... ну ладно... продолжаем разговор : ну и чем он отличается от исходников ?
Цитата:
Originally posted by Freeman
Код в данном контексте - результат компиляции.
Код в данном контексте - результат компиляции.
Ага .... кажись коллега я понял вашу аналогию.... код эт реализация а исходники эт декларация... после ужина грибочки после грибочков блинчики.... теряю былую легкость... :)
Цитата:
Originally posted by PitxBull
Вариантов много..... га га га .... на эту тему как то хорошо выразился Фишер (перефразировка): правильных вариантов(приносящих победу) не больше нескольких десятков.
Вариантов много..... га га га .... на эту тему как то хорошо выразился Фишер (перефразировка): правильных вариантов(приносящих победу) не больше нескольких десятков.
Мысль вслух : Фишер вообще хорошо выражается.... :))))
2Green : вам еще не надоело за мной следить ? ну поиграл я седня в парке с дедом в щахматы.... ну и что.... ваша игра уже уже проиграна... а как известно сотрудничество со следствием облегчит вашу участь.... сдавайтесь....не застваляйте нас вас убивать...
P.S. Сорри за оффтоп... просто уже достали своим переразвитым самомнением что абсолютно не соответсвует действительности ...
Посмотрев на название темы ... вот уж действительно "проблемы с наследованием"... еще раз извиняюсь за такой дикий оффтоп...
Что касается шаблонов то основная идея их изобретения состоит как раз в выходе на мета-уровень, то бишь манипуляция не объектами классов, а самими классами. Но тут только один оператор : new Class.
Цитата:
Originally posted by PitxBull
Что касается шаблонов то основная идея их изобретения состоит как раз в выходе на мета-уровень, то бишь манипуляция не объектами классов, а самими классами.
Что касается шаблонов то основная идея их изобретения состоит как раз в выходе на мета-уровень, то бишь манипуляция не объектами классов, а самими классами.
И как это делать во время выполнения программы?
Цитата:
Originally posted by Freeman
И как это делать во время выполнения программы?
И как это делать во время выполнения программы?
Во время выполнения конечно несколько проблематично но частичный ответ на это оператор new который в качестве аргумента воспринимает не переменную ( ака объект ), а класс. at run-time менять имя класса конечно проблематично но вполне достижимо...
Цитата:
Originally posted by PitxBull
at run-time менять имя класса конечно проблематично но вполне достижимо...
at run-time менять имя класса конечно проблематично но вполне достижимо...
разумеется не в языке C++. но эта концепция довольно старая и присутсвовала в некоторых древних языках.... программирования ))))
а почему меня псих-больным не назвали ? ))) я готовил такой ответ... ))))) зато закинули трояна )))) теперь надо винду переставить ))))))))) жизнь продолжается ))))))))))))))
Ну к примеру, smalltalk не такой уж и древний язык.
Цитата:
Originally posted by Green
Ну к примеру, smalltalk не такой уж и древний язык.
Ну к примеру, smalltalk не такой уж и древний язык.
Но без шаблонов.