Форум StopLinux

Ну, это ты пишешь про специфику С++. А С++ - вообще бяка. Но даже если говорить за него, то:
1) Создание и разрушение - не мгновенная операция. Так же, как и маллок в С. Так же как и вообще аллокейшн. Беда у твоего заявления в чем: ты имеешь ввиду скорее всего С++сный нью, который создает объект в куче. Беда в том, что ты, на самом деле, сам того не зная, говоришь не про ООП, а просто про проблему инициализации объектов в куче. И она не быстрая, тк.к. куча может быть (и обычно) фрагментирована. Поэтому умные люди, будь то С++ и С обычно выделают буферы в куче... В общем так, слово за слово, мы прийдем к менеджерам памяти))) Но ООП тут не сильно причем. Скорее только в том, что первые главы учебников учат new MyClass(), но человек не знает, что за этим стоит. Но это, прстити, называется быдлокодерством)

1б) Иногда С++ используют, как С только с конструкторами и деструкторами для "инициализации структур" - очень удобно. По словам этих же системщиков, накладных расходов на конструкторы и деструкторы тогда нет.

1в) Другое дело, когда создается виртуальная таблица для цепочки наследования. Но тут опять беда - ты пришился к С++, который в этом деле кривоват. Но в любом случае, можно это рассматривать не как ООП, а как некую парадигму, которую ты применяешь для собственного удобства. И накладные расходы на парадигму, которая применяется для удобства использоания. Но виртуальные таблицы совсем не обязятельно создавать, это вопрос скорее хранения класса в памяти. Если у тебя есть хитровыковыренный язык с нормальным менеджером памяти и JIT-ом, он может вполне себе делать то, о чем я писал выше (а ты ведь читал мой пост?)

2) Опять же ты говоришь за С++, а не все ООП. А С++ - это какашка. Если ты возмешь C#, то там будут расширения классов за счет extension methods (гугли), которые позволяют не городить С++ зоопарк расширений наследованием. Там где это не нужно, разумеется.

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

Более того, вероятно ты, будучи веб программистом, не особенно задумываешься о многопоточности. Куча лежащих глобальных переменных, которые ниче о себе не знают и ничего с собой без определенной функции сделать не могут - часто такая отличная реализация критических точек и ресурсов, что слов нет))

Ну да, если ты не создаешь линейку базовых классов.
А вообще давай подробнее, я не очень понимаю твой claim.

Например Sprite ->  DisplayObjectContainer -> InteractiveObject ->  DisplayObject -> EventDispatcher -> Object - ради одного спрайта... Значит, что либо архитектура хреновая (чем славился ак, правда 3-й, говорят, хорошо допилили, но я его уже не видел). Либо это оправдано.

Если брать .NET базовые библиотеки, то там такого обычно нет или, если есть, то для этого есть оправдание.

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

-------------------------------------------------------------------------------------

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

Вопрос, как этого добиться? .so .dll библиотеки? - отпратительно. Однако в .NET можно использовать и F#, и C# в одном флаконе запросто. Туда можно намного проще запихать C/C++ (чем юзать через длл/со), который (правда под виндой, вот беда) обладая и прямым управлением памятью и менеджером памяти с JIT по тестам рвет анменеджед (обычный) С/С++. Ну и питон с руби тоже там. Ответной технологии в полном весе в линуксе сейчас нет.

Добавлено спустя 01 мин 08 с:

Открыт секрет глючности винды)) Спасибо Павел!

потому что в классе TForm реализовано всё что только могло быть реализовано, например есть обработчики всех системных сообщений которые могут быть им обработаны.
можешь показать кейген в 5 килобайт умеющий то же самое?
но если это не нужно - Delphi никак не ограничивает программиста в написании собственного класса, аналогичного TForm, но не имеющего ничего "лишнего", или использовании WinAPI

Mike22, Есть 2 больших "но". Во-первых ты мне продолжаешь тыкать пример "не лучшей" архитектуры. Повторюсь, что тут разбирать иногда приходится алгоритмы на фортране 77, там черт ногу в гото сломит, а еще длинна строки ограничена, поэтому все переменные называются а1, b2, ij, а еще мудак, который это писал комментариев не делал в принципе. Что, теперь все функциональные языки говно?

Во-вторых ты говоришь о тяготах ООП языков, как будто на дворе 88-й год. Уже давно и в менеджерах памяти операция "создания" может не являться критической по времени, наоборот, является быстрой, и отложенная инициализация, и компановка классов, и jit и куча других наворотов, о которых программист может спокойно себе не знать=) Но да, не везде это доступно. Да, С++ ближе к 88-му, чем некоторые другие языки.

Пашок не совсем понял что сам сказал.

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

Касаемо книжки, прочитал за 3 дня (иногда на скорочтение переходил). Страниц немного 956 считая предметный указатель.