Линус Торвальдс ненавидит С++. А мы с вами? (28 стр)

innuendo
> class Foo  {...}; что  означает в C++
"A class is a type." - С++ Standart. Не больше, и не меньше.

innuendo
> точнее, точнее
Дык почитай их. Там много тоностей и ньюансов. Это все в пределах первых 30-35 страниц, так что думаю сможешь. И заодно обрати внимание на то, что такое полиморфность классов. И чем класс отличается от типа.

crsib
> > class Foo {...}; что означает в C++
> "A class is a type." - С++ Standart. Не больше, и не меньше.

я хотел бы услышать своими словами, точнее вашими :)

> "A class is a type."
> И чем класс отличается от типа.

я так понимаю вашу позицию, что клас - с это когда есть virtual у метода, когда нету - это тип ? :)

> Там много тоностей и ньюансов. Это все в пределах первых 30-35 страниц, так что
> думаю сможешь

хамить только не надо :)

innuendo
> я так понимаю вашу позицию, что клас - с это когда есть virtual у метода, когда
> нету - это тип ? :)
Отнюдь

innuendo
> я хотел бы услышать своими словами, точнее вашими :)
Оке, class is a type) А вот с точки зрения ООП между классами и типами соответствие не 1-1, а n-n, и это достаточно существенно. Ты вводишь в своих примерах самый обыный тип, реализуемый одним классом. Я уже дважды приводил пример, когда ты получишь нечто объекто-ориентированное оставаясь в рамках примера с числами.

crsib
> > я так понимаю вашу позицию, что клас - с это когда есть virtual у метода,
> > когда
> > нету - это тип ? :)
> Отнюдь

ну распишите, что есть класс и тип применительно к языку C++ - ну как вы считаете

> А вот с точки зрения ООП между классами и типами соответствие не 1-1, а n-n, и
> это достаточно существенно.

а точки зрения ООП от smalltalk - нету никаких типов

> Ты вводишь в своих примерах самый обыный тип, реализуемый одним классом.

давайте таки дождёмся вашего определения класса и типа в C++ :)

innuendo
> давайте таки дождёмся вашего определения класса и типа в C++ :)
Class is a type
innuendo
> ну распишите, что есть класс и тип применительно к языку C++ - ну как вы
> считаете
Class is a type

innuendo
> а точки зрения ООП от smalltalk - нету никаких типов
Опять мы прицепились к языку. Под типом можно например понимать интерфейс объекта. И то, посылаются ли ему сообщения или вызываются методы (в том числе и built in) роли не играет. Это определение, в частности, лежит в основе "Design Patterns. Elements of Reusable Object-Oriented Software" by Gamma et al. Оно ничем не противоречит смолтоку. Оно более чем применимо к С++. Более того, С++ концепция class is a type ничем этому не противоречит (если ввести концепцию подтипа). Правда стоит учитывать, что в определенных случаях класс может иметь несколько типов (множественное наследование, ага). Но вот тому, как ты описывешь, что такое ООП это сильно противоречит. Да, класс - данные и набор операций над этими данными. Но, в терминах С++ само по себе объявление типа классом не делает внезапно код объекто-ориентированным. Более того, такое объявление может даже не укладываться в рамки определения класса by Gamma. В частности, может отсутсвовать набор операций. Или класс может оказаться чисто абстрактным, что делает его, по факту, интерфейсом. Основная идея ОО подхода в том, что мы можем безболезненно заменять объекты различных классов, но имеющих один тип. Как это реализуется внутри системы - не суть важно. Важно то, что пользователю ОО кода нет нужды знать этого. В твоем примере float и complex не взаимозаменяемы, хотя ты усиленно настаиваешь, что раз там есть статический полиморфизм, то все хорошо. Более того, если преобразование float->complex очевидно, то обратное семантически не возможно за исключением комплексных чисел с 0-ой мнимой частью. Если следовать твоему подходу, то за счет неявного приведения типов и арифметики указателей С - ОО язык уже на уровне встроенных типов, что какгбе намекает, что что-то не так. Веду я свою речь к тому, что полиморфизма, в итоге, у тебя нет. То есть ты сам только что не уложился в определение ООП. То, что в качестве примера atavin-ta тоже плохо. Вместо полиморфизма у него есть две абсолютно эквивалентные реализации, что очень близко к банальному копипасту кода и переименованию переменных, что, конечно, можно считать частным случаем полиморфизма, но как-то очень не хочется.

crsib
> Class is a type
да ну тип так тип

> Под типом можно например понимать интерфейс объекта.
я сейчас знать не хочу про какие то там интерфейсы

> И то, посылаются ли ему сообщения или вызываются методы (в том числе и built
> in) роли не играет.
ok

> Это определение, в частности, лежит в основе "Design Patterns. Elements of
> Reusable Object-Oriented Software" by Gamma et al. Оно ничем не противоречит
> смолтоку
да не вопрос

> . Оно более чем применимо к С++.
это не я первый указал на типы в C++

> Но, в терминах С++ само по себе объявление типа классом не делает внезапно код
> объекто-ориентированным.
вы таки чётко скажите, что делает и что не делает

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

> Основная идея ОО подхода в том, что мы можем безболезненно заменять объекты
> различных классов, но имеющих один тип.
странно, а я думал, что основная идея ООП  - это максимальное повторное использование кода, ну да ладно
> В твоем примере float и complex не взаимозаменяемы, хотя ты усиленно
> настаиваешь, что раз там есть статический полиморфизм, то все хорошо.

ну а с этого по-подробнее,
1) я не говорил про заменяемость, я привёл пример полиморфизма
2) и ничего там не настаиваю 

вот простой пример

есть

class String {

public:

 void drawOn();

};

class Complex {

public:

 void drawOn();

};

они никак наследованием не связаны и всё такое

метод drawOn полиморфен ?

Complex complex;
String string;

complex.drawOn();
string.drawOn();

это пример статичного полиморфизма, это ООП в вашей вселенной ?

innuendo
> вы таки чётко скажите, что делает и что не делает
Уже раза 4 сказал. Скоро клавиши на этих местах западать начнут.

innuendo
> странно, а я думал, что основная идея ООП  - это максимальное повторное
> использование кода, ну да ладно
Весьма связанные вещи, не находишь?

innuendo
> это пример статичного полиморфизма
Это вообще не пример полиморфизма для С++. А вот в смоллтоке/objc/Lua/... это делает полиморфными объекты. Причем вполне себе динамически

innuendo
> это ООП по в вашей вселенной
Не смог распарсить, сори

innuendo
> и ничего там не настаиваю 
Orly? Хотя да, тут скорее просто троллинг. Спокойной ночи, в общем. И это, let the force be with you

crsib
> > это пример статичного полиморфизма
> Это вообще не пример полиморфизма для С++.

да что вы говорите, видел сие в паре книжек

> > и ничего там не настаиваю
> Orly? Хотя да, тут скорее просто троллинг. Спокойной ночи, в общем. И это, let
> the force be with you

я настаивал на понятии полиморфизма, а не ООП

> > странно, а я думал, что основная идея ООП - это максимальное повторное
> > использование кода, ну да ладно
> Весьма связанные вещи, не находишь?

только я ничего не хочу знать про тип :), повторное использование это далеко не только замена

vladislav
> Что это?
Арифметическая форма комплексного числа, состоит из мнимой и действительных частей, в отличие от тригонометрической, состоящей из модуля и угла.

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

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

atavin-ta
Вы прямо фанатик ООП) Завидую)

winter
Я пока прочитал только половину темы и хочу спросить.
Реально ли много у вас случаев когда надо склонировать контекст? И зачем? Вместо клонирования может потребоваться разделение - шарить текстуры, например. Но вот если взглянуть на директ, то видно, что при этом получаются объекты жестко пришитые к контексту, как у суслика. А доступ к нужной текстуре (когда память отмотана в другом контексте) реализуйте через прокси. Вместо CDTextureDX9 создаете CDExternalTexture9. Общий функционал этих двух классов может быть вынесен в родителя. Кроме этого текстура может быть вообще на другой машине - разницы пользователю не должно быть.
Если надо клонировать все, то это уже дело надстройки над базой апи, а не частью реально усложняющей все. Если возникают сложности, то можно выделить IClonable
Еще считаю неправильно пихать бинд в ITexture, поскольку это не особенность текстуры. Например, возьмем IMesh. Он может быть вообще не bindable - рисуется через dip up. Если хочется биндить, можно выделить bindable, а вообще можно и даже наверное нужно без этого. Сделали SetVertices, а в нем бинд. Смысл заставлять пользователя делать бинд? Да и что будет, если set vert и set inds ? Будем делать копию в system memory того что уже занимает память у пользователя апи и ждать позовет ли он бинд? Имхо, так делать не следует. Тут можно возразить, что используется убогий гапи теряющий ресурсы - так и там есть managed, которые не потеряются (на rt тоже решение)

FROL
> Вы прямо фанатик ООП) Завидую)
Это я то?