1. Интерфейсы компонентов теряют любой смысл.

В программах на Паскале (я имею ввиду Turbo Pascal 7.1 для DOS) я мог написать компонент, а имя файла, в котором он расположен, использовалось как имя этого компонента. Там была такая замечательная секция Interface, читая которую, всегда можно было понять, к чему обращаться.

В программах на Java имя физического модуля задаёт имя единственного доступного извне класса, который тоже задаёт интерфейс.

В программах на Си есть заголовочные файлы.

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

а) Если я написал иерархию классов, я вынужден полностью поместить её объявление в заголовок;
б) Как только я где-нибудь сказал магическое слово "template", туда же - в заголовок - тянется и вся реализация!

Выходит, что в реальной практике _интерфейсов - нет_! Т.е. ситуация построена так, что всегда можно узнать имя методов базового класса, к которому вообще-то может быть и нельзя напрямую обращаться, даже этот класс завёрнут в пространство имён: оно всё равно будет находиться в том же заголовочном файле, и его можно узнать. А нотации интерфейсов во-первых, не придерживаются программисты, и во-вторых, это есть неоправданное усложнение по правилу бритвы Оккама.


2. Что для меня на самом деле важно?

Я совершенно точно знаю, что со 100% уверенностью в моей программе будут properties. Даже если я не буду их применять, они будут всё-равно - как код, который делает ровно то же самое. Однако, если я начну применять свойства как отдельный библиотечный элемент, то я буду вынужден на каждом шагу запинаться об трёхэтажную конструкцию их объявления!

Такова парадигма С++: делать всё библиотеками.

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

Аналогичный пример можно привести из Java: это безымянные классы. В С++ я постоянно вынужден тащить за собой кучу лишнего кода только потому, что кто-то взвесил необходимость добавления в язык этой возможности, и решил, что лучше меньше в самом языке, даже если в итоге придётся кодировать больше.

Однако к чему привёл такой подход? C# и Java считаются элегантными языками, а С++ (несмотря на явные попытки выкинуть, или точнее, не вводить в него "лишние" конструкции) - весьма громоздок.


3. Корявая Агрегация.

class A;
class B;
class C;

class D
{
public:
A a_pub;
B b_pub;
C c_pub;
void doIt_pub();
protected:
A a_prot;
B b_prot;
C c_prot;
void doIt_prot();
private:
A a_priv;
B b_priv;
C c_priv;
void doIt_priv();
};

Время жизни агрегированных в D объектов однозначно не превышает время жизни агрегировавшего их объекта класса D. Это значит, что даже если вы напишете код, влезающий в канализацию для переделки объёктов a_xx, b_xx, c_xx - из них всё равно можно будет обратиться к объекту D в примерно таком вот коде:

a_pub::some_func()
{
super->doIt_pub();
}

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

a_pub::some_func()
{
super->doIt_priv(); // ошибка: попытка обратиться к закрытому методу из объекта, объявленного в открытой части.
}

Сейчас этой техники нет; поэтому приходится каждый раз сохранять отдельный указатель на агрегировавший класс, да ещё и прописывать лишние строчки с ключевым словом friend, чтобы всё работало! Но я не понимаю, какие ограничения есть к тому, что сделать такой указатель?!

PS. Можно заменить ключевое слово "super->" на "meta->", чтобы стал более понятен великий смысл и необходимость данной конструкции. Сейчас в Языке++ есть только одна возможность обойти создание лишних указателей в данном контексте - это статические функции и члены данных.


Автор очень просит всех, кто имеет такую возможность, донести данные пункты в комитет ДО принятия новой версии стандарта языка. Я очень люблю С++, но я с ним уже просто замучился...