Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Ага, есть. Только наследоваться от них нельзя.
Так потому и нельзя. Это приводит к серьезным проблемам. Например для тебя не секрет, что в дотнете массив производного типа автоматически кастится к базовому. А теперь представь что произойдет если структуры можно будет наследовать?
ПК> Кстати, интересно, а можно ли в C# передавать эти структуры в функции по ссылке, так чтобы их можно было в функциях модифицировать (соответственно, боксинг не подходит)?
Здравствуйте, AndrewVK, Вы писали:
A>>Зато были проблемы с неуникодностью Scintilla, AVK>Написанной на C++
Managed C++!
A>> с IE неосвобождающим память... AVK>Написанным на С или С++, точно не знаю.
Дело ведь не в том, что он ресурсы совсем не освобождает, дело в том, что там освобождение отложено до луших времён, говоря проще имеет место некоторый garbage collector.
Здравствуйте, VladD2, Вы писали:
A>>Один и тот же способ проблемы решения сбоев. VD>Ничего похожего. Отлов битой памяти и проверки четности чтения — это совсем разные вещи.
Я тебе про другое. Есть два способа повышения надёжности.
Первый это сделать систему изначально высоконадёжную.
Второй это сделать систему средней надёжности и оснастить её механизмом восстановления после сбоев.
Второй путь ИМХО перспективнее.
A>>Потому что у этого средства помимо удешевления есть и недостатки. VD>В основном придуманные.
Отсутсвие кроссплатформенности. Янус не ахти какое большое приложение, а даже если МОНО воспроизведёт весь .Net Framework 1.1 фиг он скомпилируется под линуксом. С чего бы это?
A>>Зато он есть и на Маках. VD>А вот Маки мне фиолетовы. К тому же на Маках есть Моно и Ява.
Зато маки не фиолетовы куче дизайнеров и типографов.
A>> Тебе не говорили, что PC-версия не является основной? VD>Нет. Говорили обратное. Вот уже 5 лет как Адобе основными версиями считает Виндвс-версии. И знаешь почему? Потому что основные продажи под Виндовс.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Если бы мы говорили о каком-нибудь С, Хаскле, Клосе и т.п., то возможно ОО-дизайн действительно был бы не причем. Но в языке который авторами назван ОО <...>
ПК>Это утверждение не соответствует действительности. Авторами язык C++ назван поддерживающим много парадигм, в том числе и ООП. В частности, у Страуструпа даже статья специальная есть, Why C++ isn't just an Object-Oriented Programming Language.
Ну, то есть ФП в нем поддреживаться так же как ООП? Или язык не является ООЯ?
ПК>Как минимум, прочитать статью, на которую дана ссылка чуть выше.
Пашь, можно прочесть много разных статей, но С++ от этого другим не станет. Большинство языков поддерживает разные стили программирования. Многие из них делают это хорошо. С++ же даже ООП и то делает не лучшим образом. А уж какие нибудь ФП совсем поршиво. Уж извини я все же буду судить о вещах по своим ощущениям возникшим на базе своего опыта, а не на базе мечтаний создателей языка.
ЗЫ
Кстати, цитата из абстракта статьи:
C++ directly supports a variety of programming styles.
И при попытке поиска слова paradigm — 0 вхождений. Все же у товарища совести хватает называть вещи своими именами.
В общем, если С++ многопорадигмный, то Шарп вообще просто супер многопорадигмный. Уж в нем хотя бы не нужно извращаться, чтобы получить породию на ФП. Жаль только как и С++ он не сильно оптимизирован на функциональный стиль. Так банальная двойная рекурсия ставит в тупик большинство компиляторов.
ЗЫЫ
И опять же разговор не о том. Проблема не в том, что С++ что-то там не поддерживает. Проблема в том, что реальные программисты прикрываясь разумными в общем-то словами о поддержке разных стилей забивают на дизайн и лепят горбатого объясняя это красивыми словами.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Кстати, интересно, а можно ли в C# передавать эти структуры в функции по ссылке, так чтобы их можно было в функциях модифицировать (соответственно, боксинг не подходит)?
Пашь, мне кажется поря познакомиться с "врагом" в лицо. Ну, что тебе стоит? Освой... язык ведь очень простой. А то развеивать твои подозрения право как-то неохота.
... << RSDN@Home 1.1.4 beta 3 rev. 267>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>То что у дотнетных процессов при создании занимается сразу по нескольку мег памяти — это ровным счетом ничего не значит. То что мы наблюдаем — это не реальная память, а виртуальная и так называемый ворксет. Можешь провести вот такой простенький эксперемент: VD>
...
VD>
VD>после второго нажатия объем памяти приложения станет около 540 кил.
Если не секрет, не поделишься, откуда ноги у этих сказок про working set растут? Не в том смысле, что working set — это все сказки, а в том, что "дерни за SetProcessWorkingSetSize — working set уменьшится, и наступит счастье". Я уже не раз встречал подобное заблуждение, очень распостраненное на рсдн'е.
Если действительно интересует, что делает данная функция, смотрим help. Самое важное, что мы там видим, это определение понятия working set:
The working set of a process is the set of memory pages currently visible to the process in physical RAM memory. These pages are resident and available for an application to use without triggering a page fault. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process.
Собственно, отсюда уже понятно, что делает SetProcessWorkingSetSize, вызванная с параметрами, как у тебя в примере. Эта функция просто отправляет наибольшее количество страниц в page file. Со всеми вытекающими, естественно. Не думаю, что ты из этого получишь какую-либо выгоду, а ущерб, как мы видим, на лицо.
Параметр показываемый TaskManager'ом, который тебя должен интересовать, это virtual memory. И это будет набор memory pages, доступных для процесса (вне зависимости от их расположения в памяти или в page file). Как ты понимаешь virtual memory нельзя "уменьшить" такими трюками вроде SetWorkingSetSize. Вся память, которую, твой процесс затребовал, она вся здесь и никуда от нее не деться.
Но все-таки virtual memory — это слишком грубый параметр. На самом деле, имеет смысл поделить его на три части: private, shared & sharable. Private — это память, которая принадлежит твоему процессу и не с кем не разделяется (например, выделения с помощью VirtualAlloc попадают в эту категорию). Shared — это память разделяемая между процессами. Обычно это код и разделяемые данные из DLL, которые ты только читаешь. Sharable — это память, которая потенциально может разделяться, но в текущий момент ни один процесс кроме твоего в ней не заинтересован.
Теперь нам ясно, какой параметр нам нужно стараться уменьшать. Это, во-первых, private memory. Из managed кода, это значит, что нужно меньше выделять самому и меньше использовать всякие фичи, которые любят выделять/писать в память. Еще неплохо пользоваться NGEN'ом, чтобы избавиться от необходимости JIT'а, который динамически создает код, весь попадающий в private категорию.
Далее идет sharable. Sharable звучит вроде неплохо, но если ни с кем больше эта память не разделяется, то она для нас as good as private. Что это значит для managed кода — reflection. Metadata, которая читается из твоей assembly в 99% случаях больше никому кроме тебя не нужна. Если еще учесть, что она обычно очень разреженная, то вполне возможно, что чтение метадаты для каждого нового класса приведет к page fault.
Чтобы увидеть, где у тебя в процессе эти private, shared & sharable, нужно использовать vadump.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Alxndr, Вы писали:
A>>Не вижу преимуществ С применительно к данному случаю
VD>Дык если С++ испоьзовать как С, то конечно разницы нет. А елси начать использовать ООП и выкрутасы на шаблонах, то объем сжираемой памяти точно увеличится.
В том то и вся фишка, что не увеличится, а, возможно, даже уменьшится. При наличии нормального компилятора, конечно.
VladD2,
> ПК> Авторами язык C++ назван поддерживающим много парадигм, в том числе и ООП. В частности, у Страуструпа даже статья специальная есть, Why C++ isn't just an Object-Oriented Programming Language.
> Ну, то есть ФП в нем поддреживаться так же как ООП? Или язык не является ООЯ?
Все-таки, похоже, не прочитал...
Constraints-based, logic programming, functional programming, and various forms of concurrent programming are examples of good and useful styles of programming not supported by C++.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК> Кстати, интересно, а можно ли в C# передавать эти структуры в функции по ссылке, так чтобы их можно было в функциях модифицировать (соответственно, боксинг не подходит)?
> Пашь, мне кажется поря познакомиться с "врагом" в лицо. Ну, что тебе стоит? Освой... язык ведь очень простой. А то развеивать твои подозрения право как-то неохота.
В смысле, "развеивать подозрения"? Простого ответа "да"/"нет" в данном случае вполне достаточно Пока что у меня к C# интерес исключительно академический, соответственно, особенно тратить время на упражнения с ним не хочется. Недавно чуть было не познакомился поближе с VB.Net, решив установить DotNetNuke, но после некоторых мучений переключился на drupal, с которым пока проблем заметно меньше. В итоге, похоже, поближе познакомлюсь с PHP
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, prVovik, Вы писали:
V>В том то и вся фишка, что не увеличится, а, возможно, даже уменьшится. При наличии нормального компилятора, конечно.
то есть — если использовать std::istream вместо ручного разбора данных, то это будет работать быстрее и отнимать меньше памяти?
Дарней,
> V> В том то и вся фишка, что не увеличится, а, возможно, даже уменьшится. При наличии нормального компилятора, конечно.
> то есть — если использовать std::istream вместо ручного разбора данных, то это будет работать быстрее и отнимать меньше памяти?
Нет. Но это не означает, что нельзя было сделать по-другому.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Hello, Дарней!
You wrote on Sat, 25 Dec 2004 10:23:08 GMT:
S>> Это ты не подумавши сказал Какие такие накладные расходы для S>> объектов, лежащих в векторе? Заметь — не указателей на объекты, а S>> именно объектов? И, собственно, с чего спич начался — на кой черт S>> объектам в этом случае виртуальные деструкторы?
Д> Есть еще куча разных вариантов с MMF, на которые тоже прекрасно ложится Д> "приспособленец".
Хоть один кроссплатформенный среди них есть?
Д> Которые снимут ограничение на общий объем данных, и которые будут Д> работать поэффективнее, чем твой вариант.
Когда я писал конкретно тот код, актуальна была поддержка Win98. MMF там
работает настолько замечательно, что хоть вешайся.
Д> Надо было просто думать об Д> оптимизации алгоритма, а не крохоборством заниматься.
Еще раз, для тех кто в танке — нечего там оптимизировать.
Д> А вообще - Д> кажется, мы отклонились от темы. Если у твоего класса закрыт деструктор Д> и наследование от него не предусматривается в принципе,
Я, кажется, ясно написал — protected деструктор. Если ты считаешь, что от
такого класса нельзя наследоваться, то о чем я тут с тобой вообще говорю...
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 delta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Д>то есть — если использовать std::istream вместо ручного разбора данных, то это будет работать быстрее и отнимать меньше памяти?
N.B. Вообще, потоковая система STL написана из рук вон плохо. Даже при чтении одного байта через istream::get() вызвается огромное количество (в том числе и виртуальных функций), что приводит к очень большой потере производительности. В этом смысле, <stdio.h> и FILE* практически идеальное решение. Единственное, что лично меня не устраивает в FILE * -- это отсутствие возможности подключать эту библиотеку к своим потокам, поэтому, например, если нужно дать возможность программе считывать данные из сжатого файла как из обычного, приходится переходить на свою доморощенную потоковую библиотеку.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, jazzer, Вы писали:
Д>JИли мы отсеем программера на С++ потому, что у него знаний больше?
Д>Потому что он больше денег требует :) При этом, при одинаковой производительности труда. (нет, я говорю не про скорость написания кода. Я говорю про скорость приближения к результату)
К большому моему сожалению, тем же жаверам уже платят больше.
J>>Или это не так?
Д>Прочитай внимательно и поймешь, что не так.
Перечитал. Не понял. :)
J>>Нет, не думаю, поэтому и говорю, что язык не играет роли, если мы набираем на работу профессиональных грамотных программистов.
Д>Дьявол, как всегда, в деталях. В данном случае — в цене.
см. выше
J>>Опыт автоматизации заборостроительного совсем не обязательно поможет при автоматизации сваезабивательного. :)
Д>Значит, хреновый это опыт.
Если ты изначально не старался спроектировать универсальную систему — именно такой опыт у тебя и будет.
А насчет универсальной у нас полное согласие :)
J>>Далее, тот, кто вносит изменения в уже написанный код, действует по аналогии, т.е. если в коде удаляется объект, он его тоже удалит, если не удаляется — он его удалять не будет. А если и решит, что удалять надо или, наоборот, нужно убрать удаление, он в своем решении будет исходить опять же из известной политики владения, иначе можно легко посадить обсуждаемый баг или создать утечку.
Д>Вот мы и до этого дошли. Политику владения надо сначала продумать, потом — записать в документации, потом — реулярно проверять, что никто ни про что не забыл и нигде не накосячил.
То же самое в java, и так же надо следить. Память — это не единственный ресурс, за использованием которого нужно следить. Хорошо, что есть языки, которые позволяют программисту забыть о конкретно памяти, но все остальное все равно остается и это "остальное" тоже нужно проектировать и проверять.
К слову, С++ позволяет автоматизировать и то, и другое путем использования принципа RAII.
Т.е. большинство программистов С++, которых я знаю, не видят большой разницы в выделении памяти и открытии соединения с базой — и то, и другое без надобности держать не стоит, и то, и другое освобождать дважды — ошибка, так что и в том, и в другом случае политику владения ресурсом надо продумывать, документировать и следить за ее исполнением.
J>>Ты утверждаешь, что для java-приложений не бывает нескольких лет отладки?
Д>оптимизации — возможно. отладки — крайне маловероятно.
Ну, если приложение обрушивает сервер, потому что исчерпываются соединения с базой данных, или сервер начинает страшно тормозить, если число коннектов больше некоторого или размер базы данных больше некоторого, то фикс этого бага, конечно, можно назвать оптимизацией. Хотя, имхо, это отладка в чистом виде. Вопрос формальности — были ли соответствубющие требования по соединениям и быстродействию записаны в первоначальном ТЗ или нет.
J>>Вот оно и есть — приведение к ссылке на базовый тип. Очевидно, с тем же успехом можно было бы применить и указатель на базовый тип.
Д>Ключевое слово здесь — "ссылка". А за указатель в таком месте надо нещадно бить по рукам.
Если ты не собираешься удалять объект — нет никакой разницы, указатель это или ссылка. А если собираешься — тоже по большому счету нет разницы, потому что здесь в игру вступает та самая политика владения, иначе ведь можно удалить стековую переменную...
Так что твое утверждение, имхо, излишне категорично...
J>>Когда ты говоришь, что знаешь русский, ты подразумеваешь, что 99% случаев употребления тобой русского языка не вызывает проблем ни у тебя, ни у воспринимающей стороны.
Д>99% в какой области? ;) Можно например сказать, что "знание русского языка" подразумевает знание нескольких матов и умение правильно ответить на вопрос "ты меня уважаешь"? :))
Совершенно верное замечание. Взять, к примеру, стройку :) Там нужны как раз специфические навыки общения :)
Я к тому, что очень мало есть реальных промышленных проектов, где бы использовался, скажем, буст, метапрограммирование и т.п.
А на том подмножестве С++, который реально широко используется (ближайший пример — MFC), писать быстро и без ошибок совершенно несложно.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
J>>И? Какое это отношение имеет к обсуждаемой проблеме? J>>По-моему, ты перечислил меморилики. Или я не так понял?
VD>Точно! Никакого. Лики и глюки делают ламеры. А мы то круть яцоподбная! Уря товарищи! :)
Здравствуйте, Sergey, Вы писали:
S>Хоть один кроссплатформенный среди них есть?
Вероятно, все остальное в твоей проге сплошь и насквозь кросс-платформенное.
S>Когда я писал конкретно тот код, актуальна была поддержка Win98. MMF там S>работает настолько замечательно, что хоть вешайся.
Любопытная информация. Откуда дровишки?
S>Еще раз, для тех кто в танке — нечего там оптимизировать.
чушь. Идеальных программ в природе не бывает, как и идеальных программистов.
S>Я, кажется, ясно написал — protected деструктор. Если ты считаешь, что от S>такого класса нельзя наследоваться, то о чем я тут с тобой вообще говорю...
Если ты не в состоянии четко и недвусмысленно описать свой случай — значит, и правда говорить не о чем.
Уж в нем хотя бы не нужно извращаться, чтобы получить породию на ФП. Жаль только как и С++ он не сильно оптимизирован на функциональный стиль. Так банальная двойная рекурсия ставит в тупик большинство компиляторов. 
