FLTK, Страуструп, неоднозначность задачи!

@Liss29 · Регистрация: 18.11.2012

Студворк — интернет-сервис помощи студентам

Привет, народ! Хочу попросить помощи в таком вопросе, есть следующая задача:

Кликните здесь для просмотра всего текста

Определите класс Controller, содержащий четыре виртуальные функции: on () , off () , set_level (int) и show() . Породите из класса Controller как минимум два класса. Один из них должен быть простым тестовым классом, в котором функция show () выводит на печать информацию о том, включен или выключен контроллер, а также его текущий уровень. Второй производный класс должен управлять цветом линий объекта класса Shape; точный смысл понятия "уровень" определите сами. Попробуйте найти третий объект для управления с помощью класса Controller.

Не совсем улавливаю смысл этого задания, особенно последнее предложение Попробуйте найти третий объект для управления с помощью класса Controller. что за объект и как его найти я ума не приложу. Возможно, есть те, кто сталкивался ранее с этой задачей или те, кто свежим взглядом увидит то, чего я не вижу, и объяснят смыл сего опуса. На данные момент смог написать следующее, набросок, если так можно выразиться:

Кликните здесь для просмотра всего текста

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
struct Controller
{
    Controller(Simple_window& w):win(w), st(false), v(0) { }
    virtual void on() { st = true; }
    virtual void off() { st = false; }
    virtual void set_level(int val) { v = val; }
    protected:
       virtual void show();
 
        bool status_controller() const { return st; }
        int level() const { return v; }
    private:
        bool st;
        int v;
        Simple_window& win;
        Controller(Controller&);
        Controller& operator=(Controller&);
};
 
void Controller::show()
{
    /*cout << "/////////////////////////////////////////////" << endl;
    cout << "//////// Controller " << status_controller() << " /////////" << endl;
    cout << "//////// Level      " << level() << " /////////////////////" << endl;
    cout << "/////////////////////////////////////////////" << endl;*/
    
    ostringstream os;
    os << "Status controller:   " << status_controller() << endl;
       << "Level:               " << Level() << endl; 
       //vs.push_back(new Text(Point(50, 50), os.str()));
        Text t(Point(50, 25), os.str().c_str());
        win.attach(t);
}
 
struct Test : Controller 
{
    void show();
};
 
void Test::show()
{
    Controller::show();
    
}

Спасибо, заранее!

IGPIGP · 25.07.2018, 11:56

Сообщение от Liss29

Тем не менее Страуструп на основе, именно такого класса, создал библиотеку графического интерфейса, может, он чего-то не знает?!

В сравнении со мной? -Боже упаси.
Liss29, Вы правы. Я никогда не видел упоминаний о таких "абстрактных" базовых классах. И в Вашем задании не видно требований такой реализации. Я пока не увидел применения того "абстрактного" что закрывает конструктор, кроме как для запрета наследования для клиентского кода:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// prg_title
#include<iostream>
using namespace std;
 
class SelfishOneBase
{
   friend class SelfishOneDerived;
    SelfishOneBase(){};
public:
      ~SelfishOneBase(){};
protected:
    virtual void virtualPublicIF()=0;
 
} ;
 
class SelfishOneDerived : public SelfishOneBase
{
    int mData;
public:
    SelfishOneDerived():SelfishOneBase()
    {}
 
    ~SelfishOneDerived()
    {};
 
   virtual void virtualPublicIF(){cout<<"SelfishOneDerived";};
};
/* это не скомпилируется так как автор базового класса не объявил
//данного наследника другом
class SelfishTwoDerived : public SelfishOneBase
{
    int mData;
public:
    SelfishTwoDerived():SelfishOneBase()
    {}
 
    ~SelfishTwoDerived()
    {};
 
   virtual void virtualPublicIF(){cout<<"SelfishOneDerived";};
};
*/
 
int main(int argv, char*argc[])
{
 SelfishOneDerived sfderived;
sfderived.virtualPublicIF();
 cin.get();
    return 0;
}

Но может быть и ещё как-то совсем иначе. Интересно было бы послушать гуру.
Но в Вашем случае, это не требуется.

@Liss29 · 25.07.2018, 21:51 **[ТС]**

Сообщение от IGPIGP

Я никогда не видел упоминаний о таких "абстрактных" базовых классах.

На всякий случай:

Кликните здесь для просмотра всего текста

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
class Shape  {        // deals with color and style, and holds sequence of lines 
public:
    void draw() const;                 // deal with color and draw lines
    virtual void move(int dx, int dy); // move the shape +=dx and +=dy
 
    void set_color(Color col) { lcolor = col; }
    Color color() const { return lcolor; }
    void set_style(Line_style sty) { ls = sty; }
    Line_style style() const { return ls; }
    void set_fill_color(Color col) { fcolor = col; }
    Color fill_color() const { return fcolor; }
 
    Point point(int i) const { return points[i]; } // read only access to points
    int number_of_points() const { return int(points.size()); }
 
    virtual ~Shape() { }
protected:
    Shape();    
    virtual void draw_lines() const;   // draw the appropriate lines
    void add(Point p);                 // add p to points
    void set_point(int i,Point p);     // points[i]=p;
private:
    vector<Point> points;              // not used by all shapes
    Color lcolor;                      // color for lines and characters
    Line_style ls; 
    Color fcolor;                      // fill color
 
    Shape(const Shape&);               // prevent copying
    Shape& operator=(const Shape&);
};

А вот о чисто виртуальных функциях он упоминает вскользь, как впрочем и дружественных функциях-классах, хотя, справедливости ради, нужно сказать, что он отсылает к книге Страуструпа "Язык программирования С++", но это что касается дружественных функций-классов.

Сообщение от IGPIGP

Я пока не увидел применения того "абстрактного" что закрывает конструктор, кроме как для запрета наследования для клиентского кода:

В каком смысле "запрета наследования для клиентского кода"? Всё наследуется без проблем

@Lyosha12 · 25.07.2018, 22:36

Я немного вмешаюсь в вашу дискуссию. Люблю абстрактные мысли и идеи

Сообщение от Liss29

В каком смысле "запрета наследования для клиентского кода"? Всё наследуется без проблем

Конструктор базы в привате.
Другом объявлен только первый класс и только первый класс может унаследоваться,
запустив этот приватный конструктор, ибо он друг.
Второй - не друг - не может запустить приватный конструктор базы - не видит его.

Читая этот топик, невольно вспомнил лекции матана. Слооожно, но понять можно.
Но я могу и попроще объяснить: делай свой проект. Принимай решения.

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

Никогда этого не говорил, но, ИМХО, за день создания кода своего проекта
я понял больше, чем за неделю чтения синтаксических особенностей std::thread.
Ошибки компилятора, библиотеки, активное гугление -
это не сравнится с синтетическими заданиями даже самого Страуструпа.

Книги я читаю только тогда, когда понимаю слёту что там написано.
Тогда, когда уже уверен в том как это работает и почему следует писать так.
Книга для меня - всего лишь подтверждение уже найденного мной, моей позиции.

Например, сейчас я пишу свою "небольшую" змейку: https://github.com/Lyosha12/Snake-SFML
Здесь можно увидеть поле
std::unique_ptr<Filler> filler = nullptr;
Filler - это класс-заполнитель клетки (Cell), которыми управляет бассейн клеток (CellsPool).
Заполнитель, как сказано в описании, всего лишь оболочка для бонуса.
А бонус уже - это виртуальный интерфейс, предоставляющий функцию "активации" бонуса, когда змейка его возьмёт.
Это сложная архитектура и я не один день её переделывал.
Однако это позволяет мне создать гибкость, которую я запланировал.

Это было небольшое введение.
А теперь по поводу того, нужно ли сосуществовать виртуальной функции и данным, которые она использует.
Бонус может действовать несколько ходов змейки. Поэтому не только при создании,
но и после бонусу (абстракции) требуется доступ к змейке, которая его уже хранит и обслуживает у себя.
И для этого я храню не константную ссылку на змейку.

Я привёл этот пример не потому, что хотел ещё раз повторить сказанное.
Но потому, чтобы показать важность "реальной" разработки приложения.
Такого приложения, которое ориентируется на мир, а не на абстрактные задания из книги,
которые иногда и не понять как интерпретировать.

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

Интересно что-то - попробуй запрограммировать.
Получи ошибки, загугли, поспрашивай на форуме,
а уж потом, если ещё нет уверенности в понятом, обращайся к книге.

Конечно, есть такие книги, которые лучше сначала прочитать от и до,
чтобы понимать какими инструментами можно выстраивать проект.
Например, это "Шаблоны игрового проектирования" Р. Найстрома.

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

Программирование, как много где написано, - больше практика.
И долго с этим я был не согласен. Но, для себя уже прояснил:
неделя чтения проигрывает дне кодинга.

IGPIGP · 26.07.2018, 14:35

Сообщение от Liss29

Всё наследуется без проблем

Не всё.

Сообщение от Liss29

На всякий случай:

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

Добавлено через 15 минут

Сообщение от Lyosha12

Но, для себя уже прояснил:
неделя чтения проигрывает дне кодинга.

В основном, согласен. Кроме случаев, когда наоборот.

Сообщение от Lyosha12

А теперь по поводу того, нужно ли сосуществовать виртуальной функции и данным, которые она использует.
Бонус может действовать несколько ходов змейки. Поэтому не только при создании,
но и после бонусу (абстракции) требуется доступ к змейке, которая его уже хранит и обслуживает у себя.

А представьте себе, что со временем мир джунглей расширится и компания рептилий прирастёт еще ящерицей и, скажем, птеродактилем. Может в этом случае разработчик пожалеть о неполном отделении интерфейса от реализации? Может имело смысл создать интерфейс eatingBonus, а всех хищников (рептилий в нашем случае) выводить в следующем уровне?

Впрочем, никто не запрещает хранить данные в абстрактном классе. Я говорил лишь о том, что чисто виртуальному методу они не нужны.

@Liss29 · 27.07.2018, 06:00 **[ТС]**

Сообщение от IGPIGP

Не всё.

В библиотеке о которой я говорю всё. Хотя в ней в основном наследование и происходит от класса Shape и только у одной группы классов есть свои наследники. Shape -> Open_polyline -> Closed_polyline -> Polygon; Open_polylone -> Marked_polyline -> Marks -> Mark; Так что всё нормально, только в этой группе классов нигде такого понятие, как дружественность, не используется.

Сообщение от IGPIGP

Сказал только, что в литературе которую я читал (не много но и не мало), абстрактный класс определён как класс имеющий хотя бы один виртуальный метод.

Наверное так правильнее всего, суть в понимании того, где и что нужно объявить, он, Страуструп, и не утверждает, что этот класс какая-то панацея-догма, но почему-то решил делать и показывать, как нужно делать, именно на таком примере.

Сообщение от IGPIGP

Пока что я его не понял.

Я и сам его не понял до конца, кажется, что всё так просто, а сам попробуй такое разработай, это я про себя сейчас, ничего путного не выйдет. Как бы просто он не выглядел, свои функции он выполняет, то для чего он предназначен, для рисования конкретных фигур.

Сообщение от Lyosha12

Но задачки на синтаксис, на синтетические упражнения с тем, что может язык,

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

.

Добавлено через 1 час 21 минуту

Не по теме:

Хочу спросить, такое вычисление ряда Лейбница имеет право на существование или нет?

Кликните здесь для просмотра всего текста

C++
1
2
3
4
5
6
7
8
9
10
double Leibniz(double n)
{
    int num = -1;
    double sum = 0.0;
    for (int i = 0; i < n; ++i)
    {
        sum += pow(num, i) / (2 * i + 1);
    }
    return sum;
}

IGPIGP · 27.07.2018, 13:02

Не по теме:

Сообщение от Liss29

Я и сам его не понял до конца, кажется, что всё так просто, а сам попробуй такое разработай

Liss29, я и говорю, что вместо того чтобы начать от необходимого (самого простого минимального, случая, демонстрирующего сам принцип как таковой) Вы отыскали нечто уникальное. Я при встрече нового материала иду от задачи (практики). А чтобы быстрее понять, выбираю наиболее простой и неотягощённый частностями случай. Вам пока, вряд ли могу быть полезен.

Добавлено через 4 часа 28 минут
Liss29, я помню, что где-то в The Design and Evolution of C++ Страуструп говорит о том, что был приятно удивлён когда ему подсказали возможность сокрытия конструктора. Может я путаю. Но не вспомню, в каком контексте шла речь. О синглтонах ли или о других классах создаваемых фабричными методами. Не могу уже найти. Но я нашёл цитату о том, почему не ввдено специального ключевого слова вроде "abstract". Из неё можно предположить, что он и сам предпочитает думать об абстрактном классе, как о классе с чисто виртуальным методом. А тот, что мы разбирали (пытались разобрать), - возможность создать то что в шарпе называется sealed. То есть, если не использовать друзей, то наследование невозможно не в открытом ни в закрытом варианте. И это прямая противоположность абстрактному классу, как интерфейсу, - классу прямо предназначенному для открытого наследования.
Вот сама цитата:
http://www.stroustrup.com/hopl2.pdf
Bjarne's History of C++: 1979−1 991, Page on stroustrup.com

The =0 syntax wasn’t exactly brilliant, but it expresses the desired notion of a pure virtual function in a way that is terse and fits the use of 0 to mean ‘‘nothing’’ or ‘‘not there’’ in C and C++.
The alternative, introducing a new keyword, say pure, wasn’t an option. Given the opposition to abstract classes as a ‘‘late and unimportant change,’’ I would never simultaneously have overcome the traditional, strong, widespread, and emotional opposition to new keywords in parts of the C and C++ community.

35 стр. внизу.
То есть, можно создавать и кастрированные абстрактные классы, но тут БС не говорит о них.

Новые блоги и статьи Все статьи Все блоги /
Химера правил, администрации порталов, законы и беззаконие. Hrethgir 26.06.2026 https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11904&stc=1&d=1782459438 У меня сейчас так везде по форуму - не могу создавать сообщений, но запись по случаю этому. . .	сукцессия 5 anaschu 26.06.2026 ПЛАН РАЗРАБОТКИ математической модели сукцессии микоризных систем Переход AM → EcM (Endo + ErM) · Шумилов А. С. · ИФХиБПП РАН · Пущино · 2026 . . .	сукцессия 4 anaschu 25.06.2026 Более детализированный план разработки План доработки модели динамики микоризных симбиозов (EcM с гистерезисом) Цель: Реализовать логику переключения между эрикоидным (ErM) и эктомикоризным. . .	сукцессия 3 anaschu 25.06.2026 Примерный план работ по модели
сукцессия 2 anaschu 25.06.2026 параметризировочная калибровочная таблица будущей модели	Многофункциональное здание: как одно здание порождает конфликты требований, которые никто не планировал (мат мет мод 29) anaschu 23.06.2026 Многофункциональное здание: как одно здание порождает конфликты требований, которые никто не планировал Материалы для обсуждения с МГСУ · 2026 Рисунки внутри приложенного ворд файла. Что за. . .	28. Конкретное развертывание плана номер 1 из поста номер 27 anaschu 22.06.2026 Можно ли из модели получить конкретные строительные требования? Честно — напрямую из текущей модели такие ответы не получить. Но цепочка логики есть, и она не такая длинная. Где разрыв . . .	27. Планы на разработку функциональных требований к строительству внутри модели пищеблока (или не только его?) anaschu 22.06.2026 Что уже реализовано и даёт конфликты «бесплатно» Самый простой конфликт уже работает — конфликт за ресурс-работника. Заданий больше, чем доступных поваров → очередь в queue1. Это прямое отражение. . .