Здравствуйте, mrTwister, Вы писали:
T>Какие умные указатели? Это же удар по производительности и "снижение энергоэффективности" (с) ГВ!
Ну ты не приводи слова без указания контекста, або даже я упомяну неприятное слово "демагогия".
T>Куча тактов процессора и байтов памяти зазря тратятся.
-1
Достаточно самому написать програму из 3-х строк, с использованием std::auto_ptr, и убедиться на сгенеренном бинарном коде, что использование этого умного указателя ничего не стоит, в сравнении с ручным вариантом, безопасным к исключениям.
T>Настоящий С++'ник на такое варварство ни за что не согласится. А если видите, что кто-то увлекся умными указателями, то все, на нем можно ставить крест. Ибо стал на скользкую дорожку и скоро скатится до .NET'a
Наоборот, плюсовики утверждают, что такая лишняя безопасность ничего не стоит... в упор не слышите просто...
Здравствуйте, vdimas, Вы писали:
I>>Подобных нет, но трюки имеются. Например приходится писать всякие коллекции и прочую дрянь что бы подлый GC собирал мусор качественно. Надо частенько замерять время жизни объектов и расход памяти, менять структуры на классы, классы на структуры, параметры-значения на ref/out, ref/out на параметры-значения, вводить иммутабельные классы, избавляться от них и тд и тд и все с оной целью — выжать еще чуток перформанса.
V>Не преувеличивай, есть всего 2 основных способа, относящихся конкретно к дотнету:
Я ничего не преувеличиваю. Все что перечислено — это тупо оптимизации работы с памятью.
V>- это создание относительно "больших" value-type, специально быть приватными полями других объектов. V>- хранение таких же value-type в массивах.
Это слишком короткий список, что бы претендовать на полноту.
V>Оба способа требуют пересмотра внутреннего интерфейса, понятное дело. Твой ref нужен вовсе не всегда, это зависит от того, где ты разместишь функциональность, и
Очевидно, любой из способов нужен не всегда. Иногда перформас дает пул обхектов, а иногда отказ от такого пула. С ref тоже самое. Более того — ни одна оптимизация не гарантирует какой либо эффект. еще раз — ни одна, даже две твои перечисленые. Они, к слову, ничем не отличаются от тех что я перечислил.
Здравствуйте, Геннадий Васильев, Вы писали:
AVK>>Я буквально неделю назад выловил ошибку в managed коде, тоже с внезапным concurrency связанную. Только там было нарушение инвариантов, а не AVE. Просмотр небольшого кусочка кода, в котором исключение произошло, сразу выявил, что это нарушение могло произойти только из-за гонок. Остальное было тривиально. А было бы AVE, точно так же несколько дней искал бы черную кошку в темной комнате.
ГВ>Здесь главное — что искомой "кошки" (ошибки в unmanaged) не было.
Так и в моем случае ошибка была в совсем другом, никак не связанном месте, не в том, где нарушение инвариантов вылазило.
ГВ> Было банальное нарушение инварианта порядка доступа и в виду отсутствия защиты от такого нарушения...
Во-во, и у меня было ровно то же самое.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, Геннадий Васильев, Вы писали:
I>>Подобных нет, но трюки имеются. Например приходится писать всякие коллекции и прочую дрянь что бы подлый GC собирал мусор качественно.
ГВ>Вот любишь же ты этим своим "качественно" цокать по поводу и без. Неужели GC способен что-нибудь потерять?
Есть такая вещь, как например фрагментация или поколения объектов. В некоторых сценариях GC начинает лажать гораздо сильнее чем С++ные хипы.
I>>Надо частенько замерять время жизни объектов и расход памяти, менять структуры на классы, классы на структуры, параметры-значения на ref/out, ref/out на параметры-значения, вводить иммутабельные классы, избавляться от них и тд и тд и все с оной целью — выжать еще чуток перформанса.
ГВ>Сочувствую, без шуток. Это же не столько трюки управления памятью, сколько трюки непрямого управления garbage collector-ом, у которого ещё и алгоритмы могут меняться от версии к версии. Занятие довольно скользкое, ИМХО, должно выносить мозг похлеще шаблонов. Да ещё и отсутствие const может здесь усложнять жизнь (хотя привыкнуть можно, не спорю). Всякая реинтерпретация памяти и адресная арифметика по трудоёмкости тут и рядом не стояли.
По трудоёмкости может и не стояли рядом, но глядя на обилие ошибок с указателями в сиплюсных программах, как то возникает сомнение что люди в общей массе вообще способны освоить эти указатели
Здравствуйте, AndrewVK, Вы писали:
V>>Ты сим постом сделал такое предположение о кач-ве дотнетных специалистов, что обсуждать сразу стало нечего.
AVK>А ты этим постом тоже кое что наглядно продемонстрировал.
Согласен, но т.к. сам тоже активно юзаю дотнет, то это был ответный гротеск на гротеск. И да, можешь в другой раз ограничиваться одним тем самым словом, я и так понял.
AVK>И от того, что конкретного человека ты с шарпа на плюсы пересадишь, он умнее не станет.
Ну так, если брать настолько уж "конкретных" специалистов, так они и using() не пользуют в дотнете, что приходилось разруливать ситуацию, когда нейтивная память уже кончается, а дотнетоному GC до лампочки... Как уже говорил тут, причина в отсутствии регулярного взаимного ревью кода, из-за которого молодые специалисты растут не так быстро, как могли бы. Или есть еще вариант ошибки профессией, но в этом варианте и обсуждать опять нечего.
Здравствуйте, FR, Вы писали:
S>>Добро пожаловать в реальный мир, Нео. FR>Посмотри лучше FR>http://stlab.adobe.com/group__asl__overview.html FR>или http://www.chromium.org/Home
Спасибо, посмотрел.
Адобе — ещё куда ни шло. Более-менее чистый код. Почти нету указателей.
Тем не менее, никаких умных указателей всё же нет — похоже, проще вообще обходиться без них, чем использовать.
Никаких кастом аллокаторов тоже нет — используются банальные ::operator new.
Здравствуйте, vdimas, Вы писали:
T>>Настоящий С++'ник на такое варварство ни за что не согласится. А если видите, что кто-то увлекся умными указателями, то все, на нем можно ставить крест. Ибо стал на скользкую дорожку и скоро скатится до .NET'a
V>Наоборот, плюсовики утверждают, что такая лишняя безопасность ничего не стоит... в упор не слышите просто...
Может и ничего не стоит. А кто её умеет и где посмотреть продукты, где бы эта безопасность что ничего ен стоит была использована ? Я чет как ни залезу в чей нибудь С++ код, так вечно хаос с указателями. Такое ощущение что RAII еще не изобрели или изобрели но не рассказали, как правильно им пользоваться
Здравствуйте, vdimas, Вы писали:
DG>>соответственно, managed — это второе: оптимальность приносится в жертву увеличения гарантированной надежности и уменьшения фатальности отдельной совершенной ошибки
V>Откуда берется заблуждение, что в дотнетных программах меньше ошибок?
Дотнет исключает огромный класс ошибок.
>Сколько их видел — вылетают ошибки как здасьте. Управляемая среда исключает только ошибки прохода по памяти (вернее, все, связанные с неверной реинтепретацией памяти). Но спроси у любого плюсовика, когда он последний раз вживую видел в С++ коде проход по памяти. Многие и не видели никогда, в плюсовом-то. А остальных ошибок хватает, понятно. Точно таких же, как во всех программах на любых языках.
Так в том то и дело, что не видели. А проги падают денно и нощно. То access violation, то null pointer, то еще что
Здравствуйте, Banned by IT, Вы писали:
G>>в C++ для такого поведения нужны различные умные указатели, аллокаторы и другие далеко нетривиальные конструкции, подсильные только гуру, чтобы все работало с такой же надежностью и эффективностью. BBI>О боги! Что же тогда из себя представляет средний С#-пник если применение готового умного указателя это считается за уровень гуру?
Средний C# не знает и не умеет указателей. Как то так выходит, что заказчики предлагают проектов примерно на порядок больше, чем могут реализовать умелые сиплюсники, так что unmanaged это вынужденая мера.
C++ код многих "умельцев" тупо не взлетает, а C# — кое как, но работает. Для кастомера это означает удешевление и увеличение возможностей.
Здравствуйте, Ikemefula, Вы писали:
I>Так в том то и дело, что не видели. А проги падают денно и нощно. То access violation, то null pointer, то еще что
Прикол в том что точно также падают и глючат и программы на шарпе и яве.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
G>>В pascal или delphi она никак не используется средой выполнения, поэтому managed они не становятся.
FR>Используется, в новых версиях рефлекшен из управляемых языков уже в приличном объеме содран и работает.
Рефлекшн и раньше был, но это не означает что среда исполнения использует эти сведения хоть как-то. С другой стороны этого делфи генерит блоки финализаторов для строк и com-объектов, так что в этом плане можно считать managed языком.
Здравствуйте, AndrewVK, Вы писали:
AVK>Вот уж на инициализацию вряд ли влияет скорость сборки мусора. AVK>Основные причины тормозов весьма традиционны для МС — медленный рендерер.
Мне всегда казалось, что тормоза старта WPF связаны с большим количеством статической инициализации. Ошибался. Сварганил небольшое приложеньице:
var stackPanel = new StackPanel();
for (int i = 0; i < 500; i++)
{
var combobox = new ComboBox();
var treeview = new TreeView();
var listview = new ListView();
var titems = new List<DependencyObject>();
titems.Add(new Button());
titems.Add(new RadioButton());
titems.Add(new CheckBox());
titems.Add(new FlowDocumentPageViewer());
titems.Add(new TextBox());
titems.Add(new TextBlock());
titems.Add(new ListBox());
titems.Add(new ListBoxItem());
treeview.Items.Add(new TreeViewItem() { Header = "T", ItemsSource = titems, IsExpanded = true });
listview.Items.Add(new ListViewItem() { Content = "L" });
stackPanel.Children.Add(combobox);
stackPanel.Children.Add(treeview);
stackPanel.Children.Add(listview);
}
var scrollViewer = new ScrollViewer() { Content = stackPanel };
(new Window { Content = scrollViewer }).Show();
Поглядел профайлером. Получается, что большую часть времени на старте WPF тратит на подключение шаблонов контролов. При этом само чтение XAML очень быстрое и, с учетом кеширования, не зависит от числа контролов. Что 500, что 100, что 50 итераций — всегда чтение ресурсов занимает около 500 мс. 40% времени программа потратила на измерение размеров контролов, основную часть которого заняло присвоение шаблонов — то бишь построение визуального дерева. Далее, что выглядит вопиющим разгильдяйством, 20% WPF занималась оповещением о том, что изменилась доступность команд. Ну, а GC за время до взятия профайлером снапшота, отработал 5 раз, суммарно 147 мс, что меньше времени вычисления размеров контролов более чем на 2 порядка.
Опыт работы с профайлером у меня не так уж велик, так что если чего не учел и кому интересно, пишите — померяю еще.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Ikemefula, Вы писали:
I>>Так в том то и дело, что не видели. А проги падают денно и нощно. То access violation, то null pointer, то еще что
FR>Прикол в том что точно также падают и глючат и программы на шарпе и яве.
Но не так глючат. В unmanaged легко получить AV если даже ты не трогал сслыку. Просто её delete_нул кто-то другой. А в managed так не бывает. Ты получишь nre только тогда когда на вход тебе nell придет, а это банально проверяется контрактами.
Здравствуйте, MxMsk, Вы писали:
MM>Далее, что выглядит вопиющим разгильдяйством, 20% WPF занималась оповещением о том, что изменилась доступность команд.
Эта претензия снимается. Не нужно было мне скроллбар дергать. Без него команды отняли 3%, а оставшиеся 17% ушли в измерение размеров.
Здравствуйте, Sinclair, Вы писали:
BBI>>О боги! Что же тогда из себя представляет средний С#-пник если применение готового умного указателя это считается за уровень гуру? S>Вот мне так интересно каждый раз это читать. На RSDN просто каждый первый плюсист непременно пользовал кастомные аллокаторы, а каждый пятый — писал свои.
Гм. И ты это можешь подтвердить ссылками, или всё таки "рыба была децл поменьше"?
S> Голые указатели, если верить форумам, вообще никто уже десять лет не применяет.
Голые указатели применяются там где им самое место. Для хранения данных используются разного рода контейнеры.
S> И мы, дотнетчики, сбежавшие из этого тоталитарного ада, просто зря боимся вернуться — там уже давно победила демократия и жить так же комфортно, как и в управляемом мире.
Жуткий говнокод есть и на дотнете, не волнуйся.
Особенно когда пишут индусы и проект в финансовой сфере.
S>Ок, давайте возьмём какой-нибудь современный проект, существующий в реальности, а не в хвастливых рассказах. S>Вот, первое, что мне попалось при поиске — Миранда. S>Порыл дальше — вот, вроде не очень давний Blender (http://www.blender.org/):
Я не видел ещё ни одного опенсурсного проекта, который был бы написан нормально. В основном там жуткая каша.
S>http://code.google.com/p/miranda/source/browse/trunk/miranda/src/modules/history/history.cpp S>Что мы тут видим? Умные указатели? S>Как бы не так! S>По-прежнему незамутнённые memcpy(), S>, и явные вызовы mir_free().
Что говорит о том, что это не С++ а С с классами.
К тому же как я понимаю все эти аллокации blob-ов обусловлены Miranda Plugin API.
S>C-style cast (кто там мне рассказывал про обязательность reinterpret_cast?)
Не знаю кто тебе рассказывал. Я сам reinterpret_cast и ему подобные не люблю — громоздко а бонусов никаких.
S> О да, последнее явно говорит о собственном аллокаторе. Да вот же он: http://code.google.com/p/miranda/source/browse/trunk/miranda/src/core/memory.cpp S>Упс, это всего лишь тонкий враппер вокруг malloc и free. Никаких чудес производительности от него ждать не стоит. Скорее наоборот: помимо обычного дорогого free он ещё и занимается обкладкой освобождаемой области 0xDEADBEEF.
Дык это ж не аллокатор вовсе а простая debug обёртка. Это в вижуалке malloc/free в DEBUG сам делает guards вокруг выделяемых блоков, а миранда ж типа "кроссплатформ".
S>Ок, наверное Миранду пишут гуры недостаточного уровня.
Нормально написанных Opensource проектов — единицы. В основном вот такая вот жуть.
S>Похоже, применение готового умного указателя — это даже выше уровня С++ гуру. Либо эти гуры все, как один, пишут не С++ код, а ехидные комменты в форумы RSDN.
Ты ищешь нормальный код там, где его отродясь не было.
S>Добро пожаловать в реальный мир, Нео.
Реальный мир не состоит из одного опенсурса.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, mrTwister, Вы писали:
T>Ну ты сравнил попу с пальцем! Без твоего, как автора кода, желания никто не заставит тебя сохранить null, в отличии от C++, где как бы ты аккуратно не писал, любой сторонний компонент может испортить твою память. Даже если этот компонент сам-по себе написан аккуратно, используя современные техники С++. Например, из-за ошибок связанных с concurrentcy, либо из-за того, что этот компонент как-то не так использовали.
И? Дотнет, например, позволяет управлять размещением полей, и мне удалось полностью уронить рантайм когда-то в первом же эксперименте на эту тему. А тот же null reference при ошибках в конкурентном коде получить вообще легче легкого. И какая разница, почему программа упала, из-за изолированной ошибки или нет? Я ведь уже согласился с тем, что в дотнете "из коробки" проще найти ошибку, в т.ч. вылетев в рантайм с исключением типа index out of range. Но, не факт что ошибка выявится на тестировании, а когда возникнет у клиента, то разница в световых и шумовых эффектах, производимых во время падения программы, ИМХО, непринципиальна. И напомню, что для случая, где легко в дотнете обнаружить ошибку по стек-трейсу, в С++ есть возможность положить рядом pdb-файл, и с помощью несложного АПИ к нему получить аналогичное. А так же есть еще способы получения стека ошибки, и мы пользуем в С++ как раз для того, чтобы получать с ошибкой стек. Просто коль речь о наведенных ошибках, то эти ср-ва нас не спасут в обоих случаях.
V>>Ну так напомню, что ты и тебе подобные постоянно игнорируют тот факт, что всякие переполнения буфера происходят в основном в legacy-коде, который был писан черти когда на голом С или на самых первых версиях C++, на котором все-равно писали как на С. Уже более 10-15 лет никто не создает в С++ массивы памяти вручную. Стал бы ты, даже имея такую возможность в дотнете (а она есть, через класс Marshal) выделять и вручную следить за блоками памяти? Это же жутко неудобно! Аналогично и в С++ — использование безопасных библиотек удобнее гораздо, банально меньше кода, и голова не болит следить за байтами.
T>Не забывай про concunrrncy. Если будет ошибка в синхронизации в управляемом коде, то испортятся только те данные, которые непосредственно участвуют в алгоритме.
Какая разница, если спустя пол-часа в другом месте получим out of range или null reference?
T>В случае ошибки в синхронизации нейтив кода можно начать стрелять вообще по всей памяти. Подобные ошибки — это полный ад, врагу не пожелаешь.
Вообще по всей — это счастье, наоборот. Потому что ошибка себя проявляет через AV, что аналогично какому-нить index out of range, который тоже исключительно в рантайм.
V>>Откуда же такое внимание к ошибкам именно в нейтиве?
T>Потому что поиск и исправление бага в нейтив коде стоит на порядок дороже поиска и исправления бага в управляемом коде. Тому есть несколько причин: T>1) Ошибки в управляемом коде более локализованы. Одному компоненту труднее нарушить работу другого
Легко в тех же ошибках в многопоточном коде.
T>2) Наличие коллстеков у всех исключений.
Помогает только для примитивных ошибок, и доступно для С++ тоже.
T>3) Типобезопасность — отсутствие возможности неправильно интерпретировать память или интерфейсы.
Наоборот, в дотнете никакой статической типобезопасноти, в сравнении с С++, где мы задешево можем создавать легковесные шаблонные решения/обертки, которые проталкивают больше прикладной логики в систему типов программы. А чего только стоил эпический флейм в свое время "as vs is" в дотнете? Для сознательной неверной реинтерпретации памяти в С++ надо хачить типобезопасность через приведение в стиле С, или через reinterpret_cast. Но эти же самые приемы мне доступны в точно такой же шаговой доступности в дотнете в unsafe, так что...
Мое ИМХО такое, что дотнет помогает избежать ошибки уровня "утекли ресурсы" или "вышли за границы диапазона"... Это совсем детские ошибки, всерьез обсуждать которые мне откровенно лень, потому как есть тот же RAII, и размер даже обычного массива на стеке может быть передан как автовыводимый в месте вызова параметр шаблонной ф-ии, что совершенно невозможно в дотнете. Или как можно выйти за границы диапазона при использовании итераторов C++, например? Да никак. Это надо С++ использовать как голый С, для получения наиболее обсуждаемого здесь эффекта, ну так давай и сравнивать голый С с дотнетом, при чем здесь С++?
По моему ИМХО, самые серьезные ошибки — это конечно плавающие и возникающие связанные с неполной/недостаточной реализацией логики, особенно на микроуровне. Например, причиной для обоих чаще всего служит банальный забытый else где-нить в иерархии if, что может принести столько настоящей головной боли, что врагу не пожелаешь. На любом языке, заметь. Это причина, по которой, я хоть и не пользую активно АлгТД и ПМ в работе, но обеими руками за эту технику, т.к. прекрасно понимаю, какой класс действительно трудоемких в нахождении проблем он способен решить.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет никакого такого качества дотнетных специалистов. Есть просто качество специалистов. И от того, что конкретного человека ты с шарпа на плюсы пересадишь, он умнее не станет.
Все-таки написать нечто "работающее" и сопровождаемое проще на managed средствах (.NET, Java, etc), т.к. порог вхождения существенно ниже по сравнению с unmanaged.
Главная беда здесь в том, что многие после этого самого вхождения, не стараются [интенсивно] повысить свой уровень.
Чтобы на том же C++ сделать мало-мальски крупный проект, который будет грамотно использовать ресурсы, будет удобно сопровождаемым, переносимым и т.п., нужно приложить существенно больше усилий к своему образованию, как следствие опытный программист на C++, в среднем получается более “продвинутым”, по сравнению с опытным программистом использующем подавляюще кол-во времени managed-средства.
Сугубо по моим наблюдениям наиболее качественный managed-код в любом случае пишут люди с опытом работы с unmanaged-кодом (и чем он был больше, тем лучше).
Ну а так, вы конечно правы, приклеивание ярлыков тем или иным сторонникам технологий/языков/парадигм, подобно измерению средней температуры по палате.
Это же не столько трюки управления памятью, сколько трюки непрямого управления garbage collector-ом, у которого ещё и алгоритмы могут меняться от версии к версии. Занятие довольно скользкое, ИМХО, должно выносить мозг похлеще шаблонов. Да ещё и отсутствие const может здесь усложнять жизнь (хотя привыкнуть можно, не спорю). Всякая реинтерпретация памяти и адресная арифметика по трудоёмкости тут и рядом не стояли.
Для сознательной неверной реинтерпретации памяти в С++ надо хачить типобезопасность через приведение в стиле С, или через reinterpret_cast. Но эти же самые приемы мне доступны в точно такой же шаговой доступности в дотнете в unsafe, так что... 
