Неосилятор ищет язык.

первое соберётся, второе - нет

#include <cstdio>

struct IA
{
  virtual void f() = 0;
};

struct IB : virtual IA
{
  virtual void g() = 0;
};

struct A : virtual IA
{
  virtual void f() { printf( "jtoof - неосилятор?\n" ); }
};

struct B : A, IB
{
  virtual void g() { printf( "да\n" ); }
};

int main()
{
  B b;

  b.f();
  b.g();

  return 0;
}

вообще наследовать интерфейсы - редкий дибилизм, но это отдельная тема

Спасибо, про такое забыл. Я плакалЪ;-)

А что будешь делать, ежели IA, IB и A определены в бинаре (сорцов, ессно, нет)?

> А что будешь делать, ежели IA, IB и A определены в бинаре (сорцов, ессно, нет)?

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

>сорцов чего нет? описания интерфейсов что-ли нет?

доступны только заголовки IA, IB, A, и virtual-наследования в них нет.

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

А что все-таки не так с IB?

доступны только заголовки IA, IB, A, и virtual-наследования в них нет.

тогда просто явно вызову метод из A:

void f() { A::f(); }

А что все-таки не так с IB?

интерфейсы не должны наследоваться, каждый интерфейс описывает что-то свое

интерфейсы не должны наследоваться

бритва Линуса: если что-то не работает, значит это не нужно. грамотно, чо :)

> бритва Линуса: если что-то не работает, значит это не нужно. грамотно, чо :)

тебе уже показали, что работает

jtoof - неосилятор?

не надо шланговать. виртуальное наследование интерфейсов смысла не имеет, и как раз хорошо показывает тот факт, что чисто абстрактные классы в C++ - это именно чисто абстрактные классы, и ничего более

>интерфейсы не должны наследоваться, каждый интерфейс описывает что-то свое

Т.е. возможность расширения интерфейса ты отрицаешь?

> не надо шланговать. виртуальное наследование интерфейсов смысла не имеет

как и наследование интерфейсов, ну да ладно - назови разницу между твоим кодом на C# и виртуальным наследованием в С++

>тогда просто явно вызову метод из A:

void f() { A::f(); }

Да, но это костыль. Впрочем как и virtual-наследование.

Я вот что то ненашел инфы как в питоне отрисовывать GUI... там оно вроде только через PyGtk...

Насчет этого с учетом вашей задачи matplotlib во все поля

тебе уже показали, что работает

тебе подсказать, почему приведённый код на C# будет работать без внесения изменений?

> Т.е. возможность расширения интерфейса ты отрицаешь?

нет конечно - возможность такая есть, теперь я задам вопрос - какие проблемы дает это самое расширение интерфейса?

> Да, но это костыль

спасибо кэп, поэтому я и сказал, что пошлю в таком случае лесом, задача из разряда - вот тебе хедер, тут все private, сырцов нет, е%ись наздоровье

> тебе подсказать, почему приведённый код на C# будет работать без внесения изменений?

ты изначально написал кривой код на С++ - он и не должен был работать, если ты напишешь @uhi4#% - оно тоже не соберется

>Не пиши программы. Вообще. Пожалуйста.

+1

как и наследование интерфейсов

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

>конвертировать стринги в чары

std::string::to_cstr() - это так сложно?

Особенно под винду

Один хрен

ты изначально написал кривой код на С++ - он и не должен был работать

так и запишем: идиоматический ООП-код в C++ не работает. ну, в принципе, ничего удивительного :)

>Плюсую за схему, но ему бы хотяб питон с пайГТК или пайКуТэ.)))

У guile есть биндинги к gtk2

>А как предлагается реализовывать тот функционал, который оно предоставляет?

В языках без множественного наследования оно реализуется с помощью т.н. Traits

Через интерфейсы не унаследуешь реализацию

Реализация травоядности может быть разной, но вот метод «жрать траву» есть у любого травоядного.

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

отрывать яй руки надо за такое в С++, для этого есть более другие языки, это ж только подумать - вместо uint64_t, например, или шустрого и стандартного mpz_class использовать интерфейсы, зачем тогда вообще писать на С++

>Очевидно, что цель не убрать все, а убрать, по возможности, все лишнее.

В том же смолтоке нет ничего лишнего. 6 ключевых слов, а всякие базовые фичи вроде наследования и диспатчинга методов выражены на самом языке. И где он теперь? :)

назови разницу между твоим кодом на C# и виртуальным наследованием в С++

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

можно сколько угодно дрочить на стиль C++ и неосиляторство окружающих, но лично меня ажурные конструкции из костылей не вдохновляют

> можно сколько угодно дрочить на стиль C++ и неосиляторство окружающих

никто и не дрочит - есть язык С++, ты его как оказалось не знаешь, вот и все

Пиши на Smalltalk, ёпт.

отрывать яй руки надо за такое в С++, для этого есть более другие языки, это ж только подумать - вместо uint64_t, например, или шустрого и стандартного mpz_class использовать интерфейсы, зачем тогда вообще писать на С++

я не спрашиваю, надо ли писать на C++; я только констатирую, что интерфейсов (и возможности писать полноценный ООП-код) в C++ нет. да, всегда можно найти другой путь - но с тем же успехом всегда можно переписать всё на ассемблере

никто и не дрочит - есть язык С++, ты его как оказалось не знаешь, вот и все

ок. если тебя это успокоит, пусть будет так

> я только констатирую, что интерфейсов (и возможности писать полноценный ООП-код) в C++ нет

полноценный ООП-код писать нельзя - да, в С++ ООП весьма условное, но это не связано с твоим незнанием языка

>C++ свою занимает заслуженно

Нука нука, это какую? Састейнинг леджейси стафф? :)

но это не связано с твоим незнанием языка

это у тебя защитная реакция такая что ли? :) ну повтори ещё раз, я не против

> Нука нука, это какую? Састейнинг леджейси стафф? :)

смоллтокеры при слове «ниша» должно стыдливо опускать глаза и молчать ;)

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

Common Lisp!

> это у тебя защитная реакция такая что ли? :) ну повтори ещё раз, я не против

ты кстати принес уже справку от психиатра? ;)

ты кстати принес уже справку от психиатра? ;)

о, какая хорошая подколка, одобряю. нет, не довелось как-то побывать за всё это время, не довелось

а про Mathematica автор никогда не слышал?

Хреново искал - Tkinter там вообще изкоробочный

Все же надо было поставить стрелку цитирования:)

>Реализация травоядности может быть разной

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

> Common Lisp!

Вы так шутите?

C++ свою занимает заслуженно

Нука нука, это какую? Састейнинг леджейси стафф? :)

Универсальный ЯП для всякой всячины с высокой производительностью. Скриптовых ЯП до черта (и они тока отбирают друг у друга юзеров), а аналогов С++ пока нету. Шарпы типа понуиверсальней, но сливают по производительности, и уж слишком они универсальные, а это ИМНО зло - «ничего обо всем»

Тот самый трицератопс может быть унаследован от класса «травоядный динозавр», который реализует интерфейс травоядности, тем самым наследуется реализация.

> Но как ты интерфейсами включишь желаемую реализацию этого метода в травоядного, м?

пронаследуется от HerbivoreFrugivores и т.п. очевидно

А, вижу. Тады ой :)

>Вы так шутите?

Нет

Универсальный ЯП для всякой всячины с высокой производительностью

Это Он!

Э... я не знаю ни одного использования CL в числодробилках. Фортран, иногда паскаль (боже), С/C++, но про CL не слышал. Вы твердо уверены, что математика на CL (включая векторизацию SSE и многопоточность) будет работаь с данными по дцать гигабайт так же быстро как на С++ (практ. на теоретическом пределе производительности)???