qt

[metaclass]

Наконец, вместо того, чтобы копировать qt с компа на комп и копаться в его исходниках, немного побаловался с написанием программ. Выводы:
1) qt creator (и возможно, сам qt) еще таки дорабатывать и дорабатывать. Глючит-с. Мне кажется, что это не уровень RC, это таки сырая бета.
2) qt не использует стандартных виндовских контролов вообще, судя по тому, что spyxx не видит ничего в проге кроме топ-левел окна.
3) Способ разработки гуя достаточно интересен, некоторые вещи интуитивно понятнее и удобнее дельфей и вижуал-студии.
4) Надо написать хотя бы одну полноценную прогу на этом деле, чтобы таки осознать, стоит дергаться ради галочки "можно писать кроссплатформенный GUI".

Comments

[vp.livejournal.com]

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

Сразу пример. Протокол, у которого внутри матрешка, уровень за уровнем. Причем матрешка фрактальная с многими отростками в разные стороны. Именно матрешковость в логике поведения каждой веточки дерева. И тут именно кроме как ГРАМОТНОГО наследования никак ничего не напишеш.

Когда ООП используется вместо простых процедур - это да, таки идиотизм. Всему свое место.

[kiryl.livejournal.com]

Имитация наследования с помощью структур также возможна. Пример:

struct point {
int x;
int y;
};

struct circle {
struct point centre; /* первое поле в структуре */
int r;
};

Без разницы, что на что реально указывает, p на struct point или на struct circle, мы можем обратиться к нему как к struct point:

((struct point*)p)->x = 1;

С множественным наследованием сложнее, но это зло.

Целая книжка на эту тему: http://www.cs.rit.edu/~ats/books/ooc.pdf.

[vp.livejournal.com]

Такое чувство, что народ прочитал первые главы про ООП а дальше нет. В ООН основное, чем пользуются - это полиморфизмом методов.
То есть как матрешка, метод1 класса1 делает что-то, наследник от него класс2 метод2 делает чучть больше, и так по цепочке. Этом обеспечивается реализация древовидных иерархий поведения. А то, что ты привел - это не то.

[kiryl.livejournal.com]

Решается полем super с указателем на структуру с реализацией методов предка, если это действительно нужно.
Необходимость объектно-ориентированного языка для объектно-ориентированного программирования надумана. Да, ООП язык бывет удобен,но ООП язык без сборщика мусора -- это ещё тот геморрой.

[metaclass.livejournal.com]

Хех. Подкинули ссылку, тоже про С++. Нельзя не согласится, что язык, где такое возможно, таки страдает от имманентного бреда.

[vp.livejournal.com]

Идея понятна, но при мало-мальски нормальном для ООП случае это выродится в ад, израиль, хануку и свиную голову. Это не эмулятор ООП, это просто паттерны для написания тех или иных вещей.

[kiryl.livejournal.com]

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

ИМХО, ООП язык без встроенного сборщика мусора и с сишным синтаксисом -- это убожество.

[max-posedon.livejournal.com]

учитывая, что в Qt, есть что-то вроде сборщика мусора (правильное программирование на Qt фактически исключает необходимость в delete)

по синтаксису и наполнению Qt я бы сравнил с каким-нить python-like

Чем же конкретно вам не понравился C++Qt? не флейма, а любопытства ради. Тока это, мне интересен Qt-пример, а не C++-пример

[vp.livejournal.com]

ООП это один из инструментов, который хорош в своем месте. Бесед как всовывание ООП в виде "классов с одной процедурой" куда не нужно, так и обратное, типа того, что мне привели.
Встроенный сборщик мусора, на самом деле, это жава и дотнет, что сделано только для снижения порога и деградации программистов. которые вообще перестают представлять что у них происходит. Вот тут да, полный ООП-ад: все в виде классов. классы живут, удаляются, никто не знает сколько и где они живут, когда и кем удаляются. Мясо.

ЗЫ А чем сишный синтаксис ООП реализации хуже того же паскалевского? По мне так совершенно именно в плане ООП описаний один хрен. Никаких преимуществ ни там ни там. ИДЕНТИЧНЫ.

[kiryl.livejournal.com]

Посмотрите, если ещё не успели, на Ruby. Он наиболее близок к моему представлению об правильном ООП-языке.