Здравствуйте, Sergey, Вы писали:
S>Это не оптимизация, а полное переписывание.
In computer science, optimization is the process of improving a system in certain ways to increase the effective execution speed and/or bandwidth, or reducing memory requirements.
А сколько там кода переписывается — это дело десятое.
Здравствуйте, Дарней, Вы писали:
Д>С++ в свое время тоже немало за это ругали У .NET в плане эффективности тоже есть немало плюсов. Например, такой могучий инструмент оптимизации, как динамическая генерация кода в рантайме. Другой вопрос, что это пока что мало где используется эффективно.
На самом деле не так уж и редко. В самом фреймворке (в 1.1) я вспоминаю как минимум 3 места где это делается.
Здравствуйте, Волк-Призрак, Вы писали:
ВП>И мне это нравится, правда пока секурити на уровне объектов ещё не ввели
Познакомься поподробнее с CAS, он подобное позволит реализовать без особых проблем. Рекомендую книжку Бокса с кем то там еще — Основы платформы .NET том 1.
Hello, Дарней!
You wrote on Tue, 28 Dec 2004 11:43:43 GMT:
S>> Это не оптимизация, а полное переписывание.
Д>
Д> In computer science, optimization is the process of improving a system
Д> in certain ways to increase the effective execution speed and/or
Д> bandwidth, or reducing memory requirements.
Д> А сколько там кода переписывается — это дело десятое.
В компьютер сайнсе — может быть. А в жизни это именно полное переписывание,
причем не только показывалки (которая всем устраивает), а половины всей
системы. Замечательное решение несуществующей проблемы
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 delta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
AndrewVK,
> A> Причем, utf-8 это не какая-либо особенная кодировка, для которой есть специальная поддержка. Таким же образом я бы мог прикрутить поддержку для любой другой кодировки. Покажи мне другую библиотеку, где данная операция обходилась бы так же легко.
> .NET Framework
Можно увидеть, как будут выглядеть в использовании те же несколько строк кода для кодировки X, не поддерживаемой до того C#/.Net?.. Просто любопытно, как у них это сделано
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Можно увидеть, как будут выглядеть в использовании те же несколько строк кода для кодировки X, не поддерживаемой до того C#/.Net?.. Просто любопытно, как у них это сделано
Да так же:
using (StreamReader sr = new StreamReader(someBinaryStream, new MyEncoding()))
{
// Do some work
}
Вот только в дотнете очень много кодировок поддерживается (упомянутая UTF-8 вобще дефолтная), так что смысла обычно в этом нет.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Геннадий Васильев, Вы писали:
Д>Если взять команду идеальных разработчиков во главе с идеальным менеджером, найти для них идеального беспроблемного заказчика — вероятно, тогда никакой разницы не будет. Но мы живем в реальном мире
Даже в указанных условиях, имхо, при разаработке софта пользовательского layer-а managed-платформы покажут более высокую эффективность, не зависимо от того, как она называется (Java, .net, smalltalk...).
То что игры практически не пишут pure-managed, это временное явление. Требуется финальная стандартизация трёхмерной графики в Java на базе OpenGL, и фиксацию DirectX-классов. Не удивлюсь, если "Direct3D-драйвкр" (то что реализует getVideoCaps, DrawPrimitive из Direct* Driver Interface этак к DirectX 11-12 (возможно будет называться Direct.net), будет managed-only... Очень вероятная перспектива. правда несколько отдалённая. Движок Doom V правда придётся Кармаку переписать с нуля
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>VladD2,
>> ПК> Несколько не в тему, т.к. C++, действительно, поддерживает несколько парадигм (стилей, как выразился в данной статье Страуструп). И авторами языка, в отличие от тебя и твоих заявлений, C++ к ООП не сводится.
>> Ну, почитай свою статью внимательно. Там только об ООП речь и идет. Чуть чуть затрагивается вопрос дженерик-программирования, но это как бы к парадигмам и стилям отношения не имеет. <...>
ПК>Имеет. Самое непосредственное. Не хотелось оттуда ничего цитировать, т.к. copy-paste не работает,
Как не работает? Вот, скопировал:
C++ directly supports a variety of programming styles. In this, C++ deliberately differs
from languages designed to support a single way of writing programs. This paper briefly
presents key programming styles directly supported by C++ and argues that the support
for multiple styles is one of its major strengths. The styles presented include: traditional
Cstyle,
concrete classes, abstract classes, traditional class hierarchies, abstract classes
and class hierarchies, and generic programming. To provide a context for this overview, I
discuss criteria for a reasonable and useful definition of ‘‘objectoriented
programming.’’
ПК> но хоть начало для полноты картины набью: ПК>
C++ directly supports a variety of programming styles. In this C++ deliberately differs from languages designed to support a single way of writing programs. This paper briefly presents key programming styles directly supported by C++ and argues that the support for multiple styles is one of its major strengths. The styles presented include: traditional C-style (1), concrete classes (2), abstract classes, traditional class hierarchies (3), abstract class hierarchies and class hierarchies (4), and generic programming (5).
Что же по содержимому этого бастракта, то треп это. Почитай внимательно статью. Где там хоть что-то серьезное о чем-то кроме ООП? Есть конечно слова о производительности, "дженерисити", но это только в твоем воображении к парадигмам отношение имеет.
ПК>Конкретные классы с их собственным наследованием и прочими "удобствами", для них созданными, куда отнесем? Взаимодействие иерархий (конкретных) классов с иерархиями абстрактных классов куда?
Блин, куда еще можно классы относить? Смешеся что ли?
ПК> Generic programming куда?
Нукуда заплатка проблем языка связанных со статической типизацией. У языков с динамической типизацией, как ты понимешь, подобных проблем вообще нет. В те времена когда эта статья писалась, может обобщенное программирование и было в новинку для языков со статической типизацией, но на сегодня это вообще не аргумент.
>> И в этом свете ОО-дизайн является (должен являться) главной стратегией проектирования ПО.
ПК>В общем случае — не является, не должен. Там где надо — да, является.
А что это за зверь общий случай? Если мы пишем на С++ и решаем относительно сложную задачу (когда структурный подход уже некатит), то ОО-дизайн — это и есть общий случай.
ПК> Но далеко не везде. Во многих случаях значительно более эффективным (с точки зрения разработки, дальнейшей расширяемости и т.п.) является использование альтернативных подходов. Еще более удачной — их комбинация.
Что за звери "альтернативные подходы"? Каковы принципы проектирования с их применением?
>> GOF, насколько я помню, использовал С++ в качестве одного из основных языков примеров.
ПК>Ну и что?
Вот и странно, почему 90% С++-программистов эти принципы или игнорируют, или вообще о них не слышало.
ПК> Это только говорит об адекватной реализации одного из непосредственно поддерживаемых стилей программирования. Это не означает недостаток поддержки или вторичное положение других стилей.
Довольно глупо неиспользовать принципов ОО-дизайна в ОО-языке. Можешь хоть проволиться на месте, но С++ — это в первую очередь ООЯ и уж во вторую гибкий и мощьный язык. А что касается дизайна приложений, то я слышал только про структурную, объекто ориентировнную и функциональную декомпозицию. Так что рассказы про стили тут как бы не причем.
ПК>Читай цитату в начале данного сообщения. Специально цифирками обозначил.
Да сам читай, если тебе она нравится. Притянул за уши какую-то фигню и делашь далеко идущие выводы.
Тебе говорят, о том что у твоих сторонников вместо слов о дизайне постоянно идут слова о том что ни сэкономили три байта на отсутсвии vtbl и что им дико мешает втоматический контрольк памяти. Причем постоянно снабжая свои посты рассказами о криворуких уродах портящих идилю.
>> И в чем тогда заслуга С++ если почти на любом языке можно писать в разных стилях?
ПК>В полноте поддержки каждого из стилей.
Да, тут не поспоришь. На сегодня С++ самый отсталый в этом смысле.
Может хватить делать идовла из этого успешно устаривающего языка? А?
ПК> В C++ можно спокойно писать в процедурном стиле,
А на яве нельзя? И на Шарпе тоже? Или на каком-нибудь Окамле нельзя? А я вот только сегодня накатал штук 5 статических процедур, так как их было достаточно. Вод беда. Знал бы что не льзя может и не неписал бы.
ПК> не заботясь о борьбе с OOP.
Можно продемонстрировать особненности того же Шарпа приводящие к "борьбе с OOP"? В чем эта борьба заключается?
ПК> Можно, наоборот, писать в OO стиле, не симулируя его искуственно.
Пашь, это уже просто смешно. На любом импиративном языке можно писать структурный код.
ПК> Можно писать в generic стиле.
Это не парадигма. На VBScript тоже можно писать обобщенный код. Даже более того. Неообщенный тяжало написать. Стилем это не является. Разумный человек при наличии возможности и необходимости просто обязан писать код обобщенным, так как это повышает его абстракность, а стало быть широту применимости.
ПК> И т.п.
Какое т.п.?
ПК> Можно сочетать все вместе. "Почти любые" языки этим похвастать не могут.
Более чем могу. Они даже с некоторых пор могут действительно другие парадигмы воспроизводить. Например, на том же шарпе без всякого метапрограммирования (на шаблонах или еще на чем) можно писать в функциональном стиле. А так же можно делать декларативные решения. Причем без "хвостов". Описал проблему атрибутами, реализовал логику и пользуйся дальше чистой декларацией. Сейчас народ работает над введением АОП и других фень. А ты все гордишся вещами которые давное уже никого не удивляют.
>> Ну, и главно как это отражается на порании принципов ОО-дизайна?
ПК>Еще раз: OOP является одним из поддерживаемых стилей, не единственным, и даже не главным. Никто ОО-дизайн не "попирает",
Да его не просто попирают. Его просто незамечают. 90% код пишится вообще без мыслей о нем. И те кто плюет на ОО-дизайн не заменяют его каким-то другим, а просто кладут на какой либо дизайн как таковой.
ПК> т.к. для начала в C++ его на пьедестал не возводили. Когда выгодно — используют; в этом случае все нужное для комфортной работы язык предоставляет. Когда не выгодно — не используют; в этом случае язык со своими "ОО" ограничениями под руки не лезет. Все дела
Да не используют его даже когда он архи выгоден. Хотя я уже десятый раз повторяюсь. Задолбало. Уж извини за резкость, но смотреть на твой взгляд через ровзовы очки нет сил.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jazzer, Вы писали:
J>вот объясни, пожалуйста, кому в здравом уме понадобилось писать то объявление b, которое ты привел, и какие цели такое объявление может преследовать.
J>Приведи хотя бы одну разумную причину, по которой нужно писать A * b = new B();, а не B * b = new B();
Бнин, уровень разговора на уровне фактастики.
Ты про абстракции ничего не слышал? Ну, давай на примерах более приближенных к жизни:
CWindow * window = new CButton();
...
// используем некоторый код наботающий с window (полиморфно)delete window;
J>Оптимизации тут, очевидно, никакой нет.
Слово "оптимизация" тут нужно понимать в ковычках. И заключается она в том, что классу не сдалали виртуальный конструктор, напимер, на основании того что объем памяти требуемой для храниения эксземляра CWindow равен аналогичному для CButton, а деструктор CButton ничего особого не делает.
Этот код даже будет жить... до того как кто-то другой, рассчитывая на разумный дизайн, не добавит в CButton ссылку на некий ресурс.
J>Я только еще раз могу повторить, что такоенаписать довольно сложно и я таких ошибок видел в реальной жизни (в сымсле, в промышленном коде) очень мало. В основном это — результат copy-paste'а, ну а copy-paste'ом можно еще и не такие баги посадить.
Ну, если ты не видел даже приведенного в прошлом моем сообщении примера, то не мудренно и это.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Д>А вообще — у меня создается впечатление, что 99% "защитников C++" в этой теме не знакомы с .NET, или знакомы очень слабо. Я бы посоветовал детальнее изучить его, чтобы иметь возможность сравнивать на деле, а не ругать его за "неэффективность" и "прожорливость".
Все еще хуже. Даже пытаясь познакомиться с дотнетом многие не понимаю зачем нужны все фичи и ограничения засунутые в него. Это как в той притче про Блабл-программиста. Они смотрят на более высокоуровневые технологии и видят только лишь набор непонятной фигни.
Все это помому, что они думают на С++ и измеряют все его метриками.
Д>С++ в свое время тоже немало за это ругали У .NET в плане эффективности тоже есть немало плюсов. Например, такой могучий инструмент оптимизации, как динамическая генерация кода в рантайме. Другой вопрос, что это пока что мало где используется эффективно.
Проблемы тут две:
1. Неумение применить мощь и гибкость технологии.
2. Недостаточная оптимизация джита.
Второе со временем решится. А первому нужно учить. Но как учить, если люди даже концепции не понимают или даже неприемлят?
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, uw, Вы писали:
A>Пока одни ругают Си++, другие на нём пишут и зарабатывают этим деньги. A>Я не злой — пусть ругают...
Пока одни ругают проституцию и торговлю героином — другие зарабатывают этим деньги
Я тоже не злой
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, Tom, Вы писали:
Tom>>Чем больше будут ругать С++, тем меньше новичков будет на нём писать, и тем больше новичков будет писать на .NET, Java, и тем больше будет моя ЗП в связи с грядущим голодом С++ программистов.
Q>Страшно подумать, какие деньги зашибают программисты на Cobol.
Я думаю, в штатах Cobol-консультанты зашибают сейчас немеряные деньги, на самом деле. Одна проблема — рынок не очень большой
"AndrewVK" <5161@users.rsdn.ru> wrote in message news:968506@news.rsdn.ru > Здравствуйте, Павел Кузнецов, Вы писали: > >> Можно увидеть, как будут выглядеть в использовании те же несколько >> строк кода для кодировки X, не поддерживаемой до того C#/.Net?.. >> Просто любопытно, как у них это сделано > > Да так же: >
> using (StreamReader sr = new StreamReader(someBinaryStream, new
> MyEncoding())) {
> // Do some work
> }
>
А что нужно сделать, чтобы свою кодировку реализовать? В том смысле, что std::codecvt имеет 7 защищенных виртуальных do_xxx методов, которые нужно определить. А в .NET как я вижу как минимум три класса нужно реализовать Encoding, Encoder & Decoder. У них в сумме куча виртуальных методов (так как все эти классы abstract). Какие из них нужно реализовывать?
> Вот только в дотнете очень много кодировок поддерживается (упомянутая > UTF-8 вобще дефолтная), так что смысла обычно в этом нет.
Вот на это и приходится надеяться. Но в подавляющем большинстве случаев того, что уже есть, наверное, достаточно, так как набор реализованных кодировок достаточно большой.
Здравствуйте, AndrewVK, Вы писали:
A>>Причем, utf-8 это не какая-либо особенная кодировка, для которой есть специальная поддержка. Таким же образом я бы мог прикрутить поддержку для любой другой кодировки. Покажи мне другую библиотеку, где данная операция обходилась бы так же легко.
AVK>.NET Framework
Не. В этой не так же. В этой намного проще.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
A>>Пока одни ругают Си++, другие на нём пишут и зарабатывают этим деньги. A>>Я не злой — пусть ругают... G>Пока одни ругают проституцию и торговлю героином — другие зарабатывают этим деньги
Пять балов.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>Конкретные классы с их собственным наследованием и прочими "удобствами", для них созданными, куда отнесем? Взаимодействие иерархий (конкретных) классов с иерархиями абстрактных классов куда? > > Блин, куда еще можно классы относить? Смешеся что ли?
Нет. Не все, что с классами — ООП. Читать определение ООП.
> ПК> Но далеко не везде. Во многих случаях значительно более эффективным (с точки зрения разработки, дальнейшей расширяемости и т.п.) является использование альтернативных подходов. Еще более удачной — их комбинация. > > Что за звери "альтернативные подходы"? Каковы принципы проектирования с их применением?
См., например, James O. Coplien. Multi-Paradigm Design for C++
>>> GOF, насколько я помню, использовал С++ в качестве одного из основных языков примеров. > > ПК>Ну и что? > > Вот и странно, почему 90% С++-программистов эти принципы или игнорируют, или вообще о них не слышало.
Это не принципы. Принципы ООП — open-closed, dependency inversion, Liskov substitution и т.п.
> ПК> Это только говорит об адекватной реализации одного из непосредственно поддерживаемых стилей программирования. Это не означает недостаток поддержки или вторичное положение других стилей. > > Довольно глупо неиспользовать принципов ОО-дизайна в ОО-языке.
Довольно глупо замыкаться на одном стиле, когда доступны другие.
> Тебе говорят, о том что у твоих сторонников вместо слов о дизайне постоянно идут слова о том что ни сэкономили три байта на отсутсвии vtbl и что им дико мешает втоматический контрольк памяти.
У "моих сторонников" идут слова о предпочтительности вынесения вспомогательных функций за пределы класса, изоляции данных от алгоритмов, уменьшении зависимостей, статическом контроле инвариантов и т.п.
> Причем постоянно снабжая свои посты рассказами о криворуких уродах портящих идилю.
Эти ужастики я от тебя слышу.
> ПК> В C++ можно спокойно писать в процедурном стиле, > > А на яве нельзя? И на Шарпе тоже? <...>
Это как раз то, что я назвал "борьбой с ООП". Ну не поддерживают эти языки такой стиль, не поддерживают. Все, что не вписывается в ООП, в них, как на корове седло.
> Или на каком-нибудь Окамле нельзя?
На Окамле можно. На Питоне можно. На Перле можно. На Си можно. На Аде можно. На Паскале можно. И т.п.
> ПК> не заботясь о борьбе с OOP. > > Можно продемонстрировать особненности того же Шарпа приводящие к "борьбе с OOP"? В чем эта борьба заключается?
В том, что нельзя писать свободные функции.
> ПК> т.к. для начала в C++ его на пьедестал не возводили. Когда выгодно — используют; в этом случае все нужное для комфортной работы язык предоставляет. Когда не выгодно — не используют; в этом случае язык со своими "ОО" ограничениями под руки не лезет. Все дела > > Да не используют его даже когда он архи выгоден. Хотя я уже десятый раз повторяюсь.
От того, что ты повторишь это еще двадцать раз, это более убедительным не станет. Ну, наверное, вырос ты среди программистов, плохо использующих C++. Я-то тут причем?
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
У .NET в плане эффективности тоже есть немало плюсов. Например, такой могучий инструмент оптимизации, как динамическая генерация кода в рантайме. Другой вопрос, что это пока что мало где используется эффективно.
Бнин, уровень разговора на уровне фактастики. 
