При определенных условиях.На определенных компиляторах.Много но)
Во первых давай вернемся из облаков теори-крафта на реальную землю. Под виндой это скорее всего будет VC, под линуксом gcc - если о С++ говорить, например. Это - раз.
Два - надо писать хороший код, а не ориентироваться по поводу компиляторов. Проблемы "сейчас" и даже 5-и лет назад, не говоря о 10-и - совсем разные. Тут речь идет о том, чтобы программист не парился по поводу того, во что превратит его код компилятор, и какие будут проблемы с оптимизацией его кода через 10 лет, а компилятор при этом работал хорошо требуя как можно меньше "искривления" дизайна. Это два. (да, С++ такими плюшками, например, почти не обладает)
Это как так?Механизм процесса ускорения в студию!
В студии.
Это три=)
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
1. Создание и разрушение объектов - не мгновенная операция.
2. Расширение стандартных классов приводит к наследованию массы неиспользуемого функционала и переменных, что не оптимально.
3. Ухищрения, на которые идут ООП-программисты, когда им нужно сложное взаимодействие группы классов друг с другом (что в процедурном программировании без проблем делается глобальными переменными) невероятно запутывают и усложняют код, что негативно сказывается на быстродействии.
Ну, это ты пишешь про специфику С++. А С++ - вообще бяка. Но даже если говорить за него, то:
1) Создание и разрушение - не мгновенная операция. Так же, как и маллок в С. Так же как и вообще аллокейшн. Беда у твоего заявления в чем: ты имеешь ввиду скорее всего С++сный нью, который создает объект в куче. Беда в том, что ты, на самом деле, сам того не зная, говоришь не про ООП, а просто про проблему инициализации объектов в куче. И она не быстрая, тк.к. куча может быть (и обычно) фрагментирована. Поэтому умные люди, будь то С++ и С обычно выделают буферы в куче... В общем так, слово за слово, мы прийдем к менеджерам памяти))) Но ООП тут не сильно причем. Скорее только в том, что первые главы учебников учат new MyClass(), но человек не знает, что за этим стоит. Но это, прстити, называется быдлокодерством)
1б) Иногда С++ используют, как С только с конструкторами и деструкторами для "инициализации структур" - очень удобно. По словам этих же системщиков, накладных расходов на конструкторы и деструкторы тогда нет.
1в) Другое дело, когда создается виртуальная таблица для цепочки наследования. Но тут опять беда - ты пришился к С++, который в этом деле кривоват. Но в любом случае, можно это рассматривать не как ООП, а как некую парадигму, которую ты применяешь для собственного удобства. И накладные расходы на парадигму, которая применяется для удобства использоания. Но виртуальные таблицы совсем не обязятельно создавать, это вопрос скорее хранения класса в памяти. Если у тебя есть хитровыковыренный язык с нормальным менеджером памяти и JIT-ом, он может вполне себе делать то, о чем я писал выше (а ты ведь читал мой пост?)
2) Опять же ты говоришь за С++, а не все ООП. А С++ - это какашка. Если ты возмешь C#, то там будут расширения классов за счет extension methods (гугли), которые позволяют не городить С++ зоопарк расширений наследованием. Там где это не нужно, разумеется.
3) Пример можешь привести? Т.к. обычно такие ухищрения являются недостатком дизайна. То, что ты говоришь, как мне кажется, отлично вписывается в аспектно ориентированный подход (и я не видел, где бы он применялся в функциональных языках). Да и с глобальными переменными в ООП языках обычно проблем нет.
Более того, вероятно ты, будучи веб программистом, не особенно задумываешься о многопоточности. Куча лежащих глобальных переменных, которые ниче о себе не знают и ничего с собой без определенной функции сделать не могут - часто такая отличная реализация критических точек и ресурсов, что слов нет))
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
Я специально упомянул, что классы расширяющие стандартные классы тянут за собой массу неиспользуемых методов и переменных. И все эти переменные тоже нужно аллокейтить и инициализировать.
Эм... Ты мой пост прочитай внимательнее?
Если ты возмешь C#, то там будут расширения классов за счет extension methods (гугли), которые позволяют не городить С++ зоопарк расширений наследованием.
Короче, меньше понтов пожалуйста. Это выглядит оскорбительно.
Какие понты? Просто специфику знаю. А остальные 15 ядер обрабатывают остальные 1426 запросов от пользователей к серверу в данный момент.
Конечно, если на 16 ядрах хостить сайт визитку и в нем делать многопоточное обращение к бд посредством функционального языка...
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
И что, extension methods как-то поможет базовым классам не инициализировать переменные?
Ну да, если ты не создаешь линейку базовых классов.
А вообще давай подробнее, я не очень понимаю твой claim.
Например Sprite -> DisplayObjectContainer -> InteractiveObject -> DisplayObject -> EventDispatcher -> Object - ради одного спрайта... Значит, что либо архитектура хреновая (чем славился ак, правда 3-й, говорят, хорошо допилили, но я его уже не видел). Либо это оправдано.
Если брать .NET базовые библиотеки, то там такого обычно нет или, если есть, то для этого есть оправдание.
На то, что ты приводишь где-то у тебя архитектура плохая, я тебе тоже сказать могу, что тут разбирать иногда приходится алгоритмы на фортране 77, там черт ногу в гото сломит, а еще длинна строки ограничена, поэтому все меременные называются а1, б2, а еще мудак, который это писал комментариев не делал в принципе. Что, теперь все функциональные языки говно?
-------------------------------------------------------------------------------------
Дальше пойдем. Функциональные языки, на самом деле, имеют ряд приемуществ и ряд недостатков. лучше всего было бы их совмещать. Но совместить это в одном языке... ну до сих пор это всегда получалось криво. Поэтому было бы здорово чтобы можно было чтобы часть модулей была с ООП, но некоторые алгоритмы могли бы быть написаны на функциональных языках.
Вопрос, как этого добиться? .so .dll библиотеки? - отпратительно. Однако в .NET можно использовать и F#, и C# в одном флаконе запросто. Туда можно намного проще запихать C/C++ (чем юзать через длл/со), который (правда под виндой, вот беда) обладая и прямым управлением памятью и менеджером памяти с JIT по тестам рвет анменеджед (обычный) С/С++. Ну и питон с руби тоже там. Ответной технологии в полном весе в линуксе сейчас нет.
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
1. Создание и разрушение объектов - не мгновенная операция.
Создание да.
Прокомментирую ИМХО.
Объект перестаёт существовать с исчезновением последней ссылки на него (данный процесс контролирует счётчик ссылок), однако событие terminate является часто именно тем накладным расходом которое хотелось бы урезать. Если же объект имеет множество вложенных объектов, то при его инициализации и уничтожении будут также создаваться и уничтожаться вложенные в него объекты.
Цитата из книги по VB 6.0 : "Дети, не пытайтесь сделать это дома. Связанные при помощи событий динозавры станут настолько медлительны что просто вымрут."
Не ламерствуй лукаво.
"А петь мне нельзя - постановление суда" (с) Бендер
Неактивен
На мой взгляд, Делфи - это огроменный прорыв вперёд.
Добавлено спустя 01 мин 08 с:
А то после 20 запусков вашей поделки из-за утечки памяти система может действительно начать еле ползать или зависнуть намертво и вам придется делать ребут. big_smile
Открыт секрет глючности винды)) Спасибо Павел!
Слорознание - первая ступень к успешному эникею!
Неактивен
А то после 20 запусков вашей поделки из-за утечки памяти система может действительно начать еле ползать или зависнуть намертво и вам придется делать ребут.
Пашок, че-то ты откровенную херню спорол. После завершения процесса, аллокированная память освобождается. Или может в венде это новое веяние моды?
Добавлено спустя 1 ч 36 мин 40 с:
А там ведь для детей написано, что VB 6 не содержит автоматического сборщика мусора, потому как VB6 это все таки язык со смешанной парадигмой, то есть там можео использовать как процедурный подход так и ООП.
Пашок, отсутствие GC у VB - это признак убогости реализации языка, а не особенность смешанной парадигмы. У Питона и ООП и процедурное программирование и элементы функционального. Но при этом GC отлично работает.
"но в отличие от вас не стремлюсь здесь перед всеми показаться умнее всех"
"Ну здесь много мосек, что ж поделаешь."
"народ после общения со мной умнеет что ли, становится более бдительным в сети"
(с) Великий Человек
Неактивен
Когда-то меня очень удивил Delphi - простейшая форма с кнопкой потребовала полумегабайтного исполняемого файла. Некоторые кейгены умудряются сделать это же за 5 килобайт. Разница в сотни раз.
потому что в классе TForm реализовано всё что только могло быть реализовано, например есть обработчики всех системных сообщений которые могут быть им обработаны.
можешь показать кейген в 5 килобайт умеющий то же самое?
но если это не нужно - Delphi никак не ограничивает программиста в написании собственного класса, аналогичного TForm, но не имеющего ничего "лишнего", или использовании WinAPI
Windows == УМВР
Неактивен
можешь показать кейген в 5 килобайт умеющий то же самое?
Лехко! Посмотри, че за либы кейген импортит. Экзешник может и 5 кил, но за ним лезет в память несколько мегабайт длл'ек. По сути, в кейгене логики с гулькин нос и только макет формочки. Все барахло в VS рантаймах.
"но в отличие от вас не стремлюсь здесь перед всеми показаться умнее всех"
"Ну здесь много мосек, что ж поделаешь."
"народ после общения со мной умнеет что ли, становится более бдительным в сети"
(с) Великий Человек
Неактивен
Mike22, Есть 2 больших "но". Во-первых ты мне продолжаешь тыкать пример "не лучшей" архитектуры. Повторюсь, что тут разбирать иногда приходится алгоритмы на фортране 77, там черт ногу в гото сломит, а еще длинна строки ограничена, поэтому все переменные называются а1, b2, ij, а еще мудак, который это писал комментариев не делал в принципе. Что, теперь все функциональные языки говно?
Во-вторых ты говоришь о тяготах ООП языков, как будто на дворе 88-й год. Уже давно и в менеджерах памяти операция "создания" может не являться критической по времени, наоборот, является быстрой, и отложенная инициализация, и компановка классов, и jit и куча других наворотов, о которых программист может спокойно себе не знать=) Но да, не везде это доступно. Да, С++ ближе к 88-му, чем некоторые другие языки.
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
Посмотри, че за либы кейген импортит.
это не тот случай, но если говорить о импорте, то с BPL или KOL и Delphi даст примерно тот же результат:
Экзешник может и 5 кил, но за ним лезет в память несколько мегабайт длл'ек.
Windows == УМВР
Неактивен
Открыт секрет глючности винды)) Спасибо Павел!
Пашок не совсем понял что сам сказал.
Павел, это в вашем c++ бывают утечки памяти. Не критикую, просто скорость требует меньшего количества накладных расходов и больший профессионализм. Обычно я прикреплял объекты в виде закрытых/открытых свойств формы, и вы должны знать что при выгрузке последней формы и окончании выполнения всего кода приложение является завершённым. То что вы описали скорее всего может происходить в случае применения оператора END. Хотя я и в этом сомневаюсь, потому что ОС получив от программы сигнал завершения должна перестать выделять ей процессорное время и очистить выделенные программе страницы памяти.
Мне так во всяком случае кажется.
Касаемо книжки, прочитал за 3 дня (иногда на скорочтение переходил). Страниц немного 956 считая предметный указатель.
Не ламерствуй лукаво.
"А петь мне нельзя - постановление суда" (с) Бендер
Неактивен