На главную страницу AlgoNet В сотрудничестве с ZDNet
АРХИВ СТАТЕЙ 2002-5-7 на главную / новости от 2002-5-7
AlgoNet.ru
поиск

 

Место для Вашей рекламы!

 

Все новости от 7 мая 2002 г.

Усиливается влияние Microsoft C#

Растет популярность нового языка программирования Microsoft C#: как показывает недавнее исследование, число его пользователей за последние полгода почти удвоилось.

Java-подобный язык Microsoft C# — один из критически важных компонентов стратегии веб-сервисов .Net, в соответствии с которой программное обеспечение для разных устройств, таких как ПК, сотовые телефоны и карманные компьютеры, будет доступно через интернет.

Согласно результатам опроса, проведенного аналитической фирмой Evans Data среди более чем 800 разработчиков, C# в Северной Америке применяют 12% программистов — полгода назад эта цифра составляла 7%. Компания прогнозирует, что в будущем году число программистов на С# удвоится и составит 24%.

Однако большинство программистов пока использует C# лишь из спортивного интереса. Они применяют этот язык менее чем в 20% своих разработок, выполняя большую часть работ с использованием других языков. По словам представителя Evans Data, C# не вытесняет какие-либо другие языки, так как большинство его пользователей лишь присматривается к новой технологии, но не полагается на нее целиком. Evans сообщает, что C# популярен среди пользователей языка программирования Microsoft Visual Basic, особенно среди тех из них, кто применяет в своей работе Extensible Markup Language (XML). Среди разработчиков на Java язык C# менее популярен.

Microsoft полагается на C# в борьбе за программистов. План веб-сервисов .Net компании направлен против технологий, распространяемых Sun Microsystems и другими поддерживающими язык Java компаниями, в том числе Oracle, IBM и BEA Systems. 

 Предыдущие публикации:
2002-03-28   ИТ-менеджеры разошлись во мнениях относительно веб-сервисов
2002-03-28   Microsoft делится кодом со студентами
2002-04-08   Инструменты электронной коммерции для реализации стратегии .Net
 В продолжение темы:
2002-05-21   Microsoft включит в Windows средства планирования порталов
2002-06-19   Microsoft возвращает Java в Windows
2002-06-24   Будьте готовы к шоку от стоимости .Net
2002-10-14   Microsoft взяла аккорд C#
2003-05-07   Популярность Visual Basic может пойти на убыль
Обсуждение и комментарии
Se
7 May 2002 2:58 PM
С# - это полумеры как и XML... Скоро должен появиться новый язык.
Через полгода - год, я думаю.
 

Skull - sibskullmail.ru
7 May 2002 3:13 PM
2Se: ну C#-то еще можно подумать, а вот лучше XML еще ничего не выдумали. И не выдумают в ближайшее десятилетие.
 

miroh - plasmonmail.ru
7 May 2002 3:37 PM
В общем то Se прав. Сам XML как основа межплатформенного обмена информацией и веб сервисов малоэффективен по сравнению с каким либо бинарным форматом. Парсить- преобразовывать - передавать XML зело затратно. Потомуто Sun скептически относится к вебсервисам как к основе будущих распределенных вычислений. Все это шаг назад по сравнению с java обьектами , которые способны автоматически изменяясь перемещаться по сети общаясь с серверами и пользователями и накапливая информацию. Пора уж смотреть в сторону компонентов - конечных автоматов.
 

Chkaloff
7 May 2002 4:57 PM
2 Se, miroh:
Моська лает, а слон идет.
> Потомуто Sun скептически относится к вебсервисам как к основе
> будущих распределенных вычислений.
Может и относится скептически, а коленки у них явно дрожат. В альянс MS,IBM & etc. ее не приняли. Пытается свои создать.
Да и на странице их сейчас главной надежды - Sun ONE написано в первом же обзаце:

Sun[tm] Open Net Environment (Sun ONE) is Sun's standards-based software vision, architecture, platform, and expertise for building and deploying Services on Demand. It provides a highly scalable and robust foundation for traditional software applications as well as current Web-based applications, while laying the foundation for the next-generation distributed computing models such as Web services.

Да и зайдя к ним на сайт в раздел Пресс-релизов, тутже натыкаешся на то, что они проводят конференцию JavaOne, где основными темами являются как раз Web services и поддержка жабой XML, SOAP, UDDI, ebXML, and WSDL.

Так что, тут вы, товарищ, поперли против паровоза.

Что касается сравнения Web Services с сетевыми объектами java. То, наверное мягко говоря, это не коррекектное сравнение. Они не реализуют функции сервисов. Сравнивайте на здоровье их с .NET Remoting (http://www.dotsite.spb.ru/Publications/PublicationDetails.a spx?ID=15). Вот тогда и поговорим.
 

MX
7 May 2002 5:13 PM
2Chkaloff
>Сравнивайте на здоровье их с .NET Remoting (http://www.dotsite.spb.ru/Publications/PublicationDetails.a spx?ID=15). Вот тогда и поговорим.

Voobshe-to v Java RMI eto uzhe davno.

>Они не реализуют функции сервисов
Kto oni i kakogo vida servisy?
 

Chkaloff
7 May 2002 5:58 PM
2 MX:

>Voobshe-to v Java RMI eto uzhe davno.
a .NET вот недавно появился. И что? В чем вопрос-то?

>Kto oni i kakogo vida servisy?
UDDI и WSDL прочитайте
 

Se
7 May 2002 6:55 PM
2Chkaloff, Skull
Вообще то XML - это круто... по сравнению с html...
Расширяемый набор тэгов - это класс. Но уж очень много
тянется хвостом от языка разметки. Все же XML - это не язык описания объектов (хотя свойства объектов и их состав вроде бы описывать можно). Но где методы и события? И еще определение объектов в DTD - на другом языке - это не гармонично...
Нужно смешать XML и C# и создать новый язык!
А Вы говорите "против паравоза" - по-моему - впереди...

 

PTO - kruchkovkgb.ru
7 May 2002 7:02 PM
2 Se: посмотрите на соап и виздел - это именно схемы XML, которые описывают доступ и методы и события объектов. это весьма и весьма гармонично... это делали МС с ИБМом и парой еще китиков мировых, Оракл тоже с этим примирилась и юзает во всю... осталось только тех кто впереди паровоза убедить
 

Nick - nicknickmail.ru
7 May 2002 7:26 PM
Вот люди млин Вас... Для Вас Винды это всё, а если их (Win 95,98,NT WS,NT, ME, Win XP, Win CE) не будет, (допустим), что с Вами будет?!
 

Anonim
7 May 2002 7:49 PM
Такое впечатление что попал в дурку... Бегущим впереди паровоза и Чкалову: кто нить из вас писал что либо на Java ? Только не апплеты ессесно а с J2EE ? Про EJB/RMI что нить слышали ? C# хотя бы спецификацию читали ? Я так боюсь что рассуждения здесь идут исключительно основанные на домыслах. Скрестить xml с языком... Вот бы... Да давно уже используются паттерны в яве для генерации объектов по xml. Чем дольше я смотрю на супер сторонников MS/обкакивателей sun'а, тем более убеждаюсь что высказывания в 90 процентов случаях идут от фонаря.
 

Anonim
7 May 2002 7:56 PM
Кстати идея супер-дрюпер сервисов которые так рекламирует мелко-фт далеко не нова. Ноги растут из remote invocation'a жабового. Просто протокол обмена сделали на основе XML (который по мнению местных товарищей не эффективен) - человекочитаемым, как раз отказавшись от бинарного формата. Иеня поражает что МС не постеснялась даже терминологию C# скомуниздить из java... Что бы воплей не поднимать почитайте про JIT.
 

Наблюдатель
7 May 2002 8:43 PM
2Nick
Если бы, да кабы, во рту выросли грибы?:))
 

Qrot
7 May 2002 8:59 PM
2Nick: ну расскажи, что со мной будет :)
 

qwerty
7 May 2002 9:08 PM
2Nick: Смотря в результате чего. Если в результате глобального катаклизма типа падения Луны на Землю, то то-же что и с вами, а именно п...ц (правильно вставьте буквы). Во всех остальных случаях - очередная волна: покупка железа (если необходимо), установка другой ОСи, втюхивание юзеру сырого, горбатого (прочие определения смотри в обсуждении любой статьи про Microsoft) софта и т.д. То есть ничего не произойдет. Мы же ещё не дошли до того, что рождение это setup, а смерть - shut down. Скажу больше, один раз участвовал в качестве арбитра в споре двух 25-летних индивидумов на тему что вокруг чего вращается: Земля вокруг Солнца или наоборот. Сначала не поверил, думал смеются, оказалось правда не знает. Человек вообще не знает что такое компьютер. Пастух он. И доволен жизнью! А мы тут нервничаем что лучше. Да всё хорошо. Радоваться жизни надо. Хочешь Windows - пожалуйста. UNIX - можно 2 в одни руки. Напрягаться не надо, тогда и расслабляться не потребуется.
 

Skull - sibskullmail.ru
8 May 2002 4:29 AM
2Se: не, этот юмор мне нравится - про UIML слышали? Да и PTO все по полочкам разложил. Уж в этом вопросе я с ним абсолютно солидарен. :)

2qwerty: "рождение это setup, а смерть - shut down" - неверно. рождение это init, а смерть - poweroff :)
 

tstone - saldomail.ru
8 May 2002 8:02 AM
Вот тока забыли сказать на чьи деньги этот опрос проводился :-)
А сие есть немаловажный фактор при получении результата!
 

Se
8 May 2002 10:53 AM
2PTO: На днях перечитывал документацию по Windows 2000 Active Directory - расширяемая схема объектов, ля-ля-ля, бла-бла-бла...
Сравниваешь с описанием объектов в XML и понимаешь, что и Windows 2000 - это тоже полу недоделанная система... Видно начинали делать объектную файловую систему, потом плюнули быстренько закончили разработку и втюхали пользователям.
Еще раз говорю:
1. С# и XML должны превратиться в новый красивый и простой язык.
2. Вместо файловой системы должна быть объектная система со свойствами, составными объектами, методами и событиями
3. Такую объектную систему должен поддерживать другой (новый) аналог Internet Information Server или Апачи - сервер объектов
4. Должны быть навые аналоги http
5. Должен быть новый браузер, поддерживающий новый сервер объектов
6. Должна быть новыя операционная система
7. Должен быть новый internet...
8. Ну и для нового языка должна быть новая среда разработки...

И фирма, которая все это сделает, будет новой Microsoft или это будет сама M$ с ее новой объектной операционной системой.

Так что, именно "переди паравоза" из Microsoft, Sun, IBM и пр...
Почему, нет :)
 

hidden
8 May 2002 11:04 AM
2Se:
про сервер объектов - согласен - будет!
А на счет интернета - нет, спрашивается другой нафига? :)))
Если ты считаешь новым IPv6 - тогда, да будет такой, во
всем остальном - это лишь транспорт, потоки которого можно
оптимизировать до бесконечности, но суть останется та же.
 

PTO - kruchkovkgb.ru
8 May 2002 11:43 AM
2 Anonim: вопрос на засыпку - кто сделал первый JIT для Джава и откуда вообще пошел термин JIT?

2 Se: перечитайте доки по АДиректори еще раз, если не поймете, ну чтож, значит не судьба...
Теперь по-пунктам:
1. "русский" и "фортран" должны превратиться в новый красивый и простой язык... давайте яблоки с арбузами не будем сравнивать, хоть у них форма и похожа? Мы хоть со Skull-ом частенько спорим - но тут я с ним соглашусь - на XMLе можно описать что угодно и в том числе смотрите на спеки UIML, а также кучу других схем XMLя на всякие случаи жизни.
2. работают над этим в МСе очень давно, хотя споры о целесообразности сего до сих пор не стихают. Элементы этой самой объектности присутствуют на самом деле с самой первой НТФС... тут вам и многопоточность и свойства "файлов/объектов" и немного методов (к примеру вордовый документ имеет свойство печатать документ), ну и события (файл изменен к примеру)... это зачатки того что можно сделать и Лонхорн похоже будет иметь массу расширений или вообще новую систему управления файловыми системами
3. ну ессестно будет ее ИИС поддерживать... хотя сегодня он нормально работает с MTS, где как раз объектики, объектики и еще раз объектики между собой общаются, а aspx собственно клей, который их собирает и отображает в виде понятном браузерам
4. ну про это собственно пару флеймов тут уже отгремела - ИБМ с МСом в поте лица трудятся над заменой HTTP
5. и да, и нет... нужен браузер умеющий взаимодействовать с серверами SOAP и всякое прочее, но должен быть ли он уж совсем революционным х3... веб-сервисы собственно придуманы для взаимодействия между собой разных машин и приложений, а не для междумордия с человеком... ему как раз тут веб-браузер обычный, но с фишками подойдет... тут я как раз ратую за строгое соблюдение стандартов w3.org
6. ну вот уж фиг... совсем новая - со своим АПИ и т.п. нах не нужна... слишком дофига приложений и в один день их никто на новую платформу не перенесет, а ОС без приложений все-равно что авто без двигателя, колес и кузова.
7. в каком смысле "новый"... по пропускной способности? на другом наборе протоклов? с иной системой маршрутизации? бесплатный? чего нового-то хочется?
8. ну и это подоспеет, как только появится все что нужно для счастья
 

Skull - sibskullmail.ru
8 May 2002 2:11 PM
2hidden: "про сервер объектов" - типа, CORBA уже не канает? eXOR! Здесь молодежь про CORBA забыла!

2Se (маленькие замечания после той блестящей речи PTO) - если речь идет об объектах, то надо рассматривать отнюдь не браузер, а управляемый голосом/другими частями тела интеллектуальный центр развлечений. Поскольку в рамках последних нововведений комп уже отживает свое в рамках господина над юзером. Мелкие девайсы+беспроводная сеть+XBox (или вот PTO расскажет про новый интерфейс от MS, который понятен любому безо всякого браузера).
 

Anonim
8 May 2002 2:39 PM
2PTO - ясен пень это МС придумал для сишарпа. А сановцы сперли.
 

Se
8 May 2002 2:47 PM
2RTO:
"Теперь по пунктам": :)
1. На Vb или C# вполне можно писать имена переменных, функций и пр. на русском... Не кажется ли непоследовательным, что в asp.net
разметку страницы в файле .aspx пишут на html, а все функции (раньше бы сказали бы "скрипты") пишут на прикрепленном к нему файле .aspx.vb на VB или C# или С++? Почему "разметку страницы" в программе .exe на VB пишут на родном VB, а ту же разметку для Web - приложения пишут на HTML? Язык должен быть один! И ничего тут несовместимого между "яблоками" и "арбузами" нет. Все фрукты.
Один язык будет соотвествовать одному парсеру и компитлятору (Just in Time). XML при всей своей красоте непоследователен и сложен с этими своими DTD, XLink, XPointer, XPath, XML Schemas, SOAP... Он недостаточно красив... Хотя конечно развивается в правильном направлении... Но нужно переделать.
2. Windows 2000 - это еще объектная система. Это файловая система и набором сервисов (программ). Это полумеры... Нужна полноценная объектная система. Ксати, она вначале может быть простро надстройкой над Windows или над Unix. Т.е. располагаться слоем между файловой системой и internet-протоколами доступа к серверу.
3. МТS - вообще вчерашний день, как и COM - "объекты". У MS уже .net объекты с совершенно другим интерфейсом и поддерживает их .net framework. Но это все равно полумеры. В Сети (то, что сейчас называют Internet) должна быть возможность обращаться к любому объекту (учитывая безопасность и права доступа) на сервере, к любому подобъекты внутри этого объекта и к любому свойству, методу событию или интерфейсу этого вложенного в другой объект объекта. Например, Word-овский текст должен рассматриваться как объект, и мы должны иметь возможность указать и добраться до "цветы пятой буквы третьего слова от конца"...
 

miroh - plasmonmail.ru
8 May 2002 2:50 PM
C# интересный язык - но больно наворочен и местами кривоват. Все в микрософтовском духе. Одни делегаты и события чего стоят - такого уродства я не встречал со времен разбирательства с агрегированием OLE обьектов. Java куда совершенней и продуманней, по сравнению с ней C# просто гора "клевых" фич и примочек.
 

Se
8 May 2002 3:07 PM
2RTO:
"Теперь по пунктам": :)
4. Тут ты вроде и так согласен...
5. w3.org - куча народа обсуждают стандарты... В результате получается как у Райкина:
- Кто шил костюм?
Выходят сто человек и отвечают:
- Мы...
В результате мы видим скопище стандартов XML, которые простыми и красивыми уж никак не назовешь.
6. Новый язык породил новую операционную систему. Новая операционная система породила новое сетевое взаимодействие. Я говорю о языке С, операционке Unix и сети Internet. Когда появится новый язык (назовем его D - по русски "Ди"), на нем автоматически будет легче и удобней описывать объекты и писать саму операционную (пардон, "Объектную") систему. Новая операционка породит и новый "объектный интернет".
7. В каком смыске новый?
С новой адресацией. Например, вместо IP адресов, можно указывать широту и долготу физического расположения сервера, как это делается в геоинформационных системах. Как в Microsoft MapPoint.net
C новым системой доменных имен. Ведь нам нужно будет указывать не просто сервера в доменах, а и объекты в объектах, их свойства, методы и события. Так что DNS нужно будет заменить.
Должна быть гарантированная безопасность обмена информацией. Всякие хакеры, спам и пр. должны быть в принципе невозможны. Кругом должны быть "списки доступа к объектам", цифровые сертификаты подлиности личности и объекта и пр. Можно много еще чего сказать. Нужна новая сеть!
8. Тут возражений и не было
:)
 

PTO - kruchkovkgb.ru
8 May 2002 3:44 PM
2 Anonim: нет, JIT это термин, который ввел кто-то очень и очень давно (чуть-ли ни Кнут), если дома найду книжку одного из классиков по компиляторостроению, напишу кто именно.
Первый JIT для Джавы написал МС и очень долго он был самым быстрым...
 

PTO - kruchkovkgb.ru
8 May 2002 3:55 PM
2 Se:

1. всю дорогу бились за то, чтобы разделить содержимое от верстки, для сего и напридумывали кучу всего. Сегодня большинство проектов делаются так, что aspx выдает XML, а сервер в зависимости от устройства с которого пришел запрос отрабатывает соответствующий XSL файл и отдает HTML для IE, Netscape, WAP или для наладонников чего-то...
XML - это язык описания _ЯЗЫКОВ_, если нужен язык для доступа к базам, то пишется схема, нужна для обмена бызнес-сообщений, пишется другая.
2. повторюсь - над этим работа идет в полный рост, хотя многие сомневаются в ее целесообразности вообще
3. для этого собственно и делается SOAP, WSDL, UDDI - каждый решает свою задачу... но цель именно такова... любое устройство, на любой ОС, с любым приложением может обратиться на другое устройство, под другой ОС и с другим приложением
4. а я вроде не спорил - нужны новые протоколы, которые возможно рано или поздно заменят нынешний HTTP, причины вроде уже рассмотрели и нет смысла к этому возвращаться
5. се ля ви... открытые стандарты принимаются сложнее, но народ больше любят открытые, да и прогресс идет глаже и спокойнее... одна голова хорошо, а две лучше... опыт последний SOAP, WSDL, UDDI показывает, что совместная работа китов индустрии может многое принести всем
6. а нужно ли это... языков появляется каждый день, а вот новых ОС под них маловато будет, а уж новых сетевых взаимодействий и вообще кот наплакал
7. дык IPv6 именно в этом направлении дорога... указывать сервер по геокоординатам глупость - у меня в стойке стоит 10 серверов и каждый из них держит пару сотен сервисов...
 

PTO - kruchkovkgb.ru
8 May 2002 4:07 PM
2 Се: и эта, я ПТО тогда уж...
 

Se
8 May 2002 4:30 PM
2PTO
Глупое IP будет таким: Широта, долгота, и высота (для твоих 10 серверов). Для сервисов еще одна координата (номер порта по теперешнему).
Далее, представь... С какого-то Ip идет хакерская атака... или спам. Собирается команда и едет по точному адресу, который они вводят в свой MapPoint, мочить этого рассыльщика тушёнки... Каждому сисадмину перед инсталляцией нужно иметь GPS приборчик, который нужно подключать к серверу, чтобы ввести IP. Никаких комитетов по раздаче IP не нужно вообще.
Для мобильных пользователей автоматом будет меняться IP. В мобильники встроим GPS. Крутизна и красота...
 

miroh
8 May 2002 5:30 PM
Всетаки XML - формат текстовый и неэффективный для распред вычислений. Этож как маршаллинг делать надо - парсить распарсить текст, да еще по сети передавать... Долго и неэффективно. Вот например формат типа swf подошел бы идеально - бинарный и общедоступный. Легко конвертировать и передавать.
 

Qrot
8 May 2002 5:58 PM
2Se: с уважением отношусь к таким фантазиям но только у тебя они приобретают форму весеннего обострения %) - я про геоIP. нах мне мобильный IP? мне постоянный нужен! и вообще - получение информации о моем местонахождении без моего ведома является нарушением privacy так что не надо мне такого счастья... я как нить в IPv6 проживу
 

me - userinternet.com
9 May 2002 1:24 AM
>> Собирается команда и едет по точному адресу
Мда... Вот они - законопослушные граждане новой великой державы... Налоги давно платил, Се? С "пацанами" не ссорился никогда? Завидую.

>> Никаких комитетов по раздаче IP не нужно вообще.
Что-то я не припомню комитета, который мне айпи выдавал. Может, и провайдеров тоже нах?

>> формат текстовый и неэффективный для распред вычислений
Вот ты мне объясни глупому, что же вы с Солнцем считать-то собрались, а? Че-то кричат все кругом "распределенные вычисления то, распределенные вычисления се". Чего вычислять будете?

>> Java куда совершенней и продуманней
Интересно-интересно:)) Ты вот мне скажи, как определить во время исполнения программы метод, который лежит чуточку ниже в стеке? Парсинг стэктрэйса не предлагать. Ждк 1.4 - тоже:)) там это сделали, хоть и криво до ужаса. (и не спрашивать - "зачем?": так надо). Или, например, как взять джарчик и последовательно подгрузить каждый классик. И, пожалуйста, без написания своего "класс лоадера", так как в нем придется брать файлик и парсить его самому. Да много всего могу привести. В жаве даже енумов нет:((
 

me - userinternet.com
9 May 2002 1:32 AM
Про XML. На мой взгляд, у этого языка есть одно совершенно неоспоримое преимущество перед любым похожим, но бинарным: документик можно налабать в блокноте и он будет работать. А это то, ради чего можно пожертвовать любыми каналами связи. Про производительность компов речь уже давно не идет: скоро такое же отношение будет и к толщине кабеля.
 

Skull - sibskullmail.ru
9 May 2002 1:33 PM
2Re: "В Сети (то, что сейчас называют Internet) должна быть возможность обращаться к любому объекту (учитывая безопасность и права доступа) на сервере, к любому подобъекты внутри этого объекта и к любому свойству, методу событию или интерфейсу этого вложенного в другой объект объекта." - ЗОЛОТЫЕ СЛОВА. При условии что ВСЕ интерфейсы открытые и задокументированы. :)

"Когда появится новый язык (назовем его D - по русски "Ди"), на нем автоматически будет легче и удобней описывать объекты и писать саму операционную (пардон, "Объектную") систему." - так вроде был BeOS, Hurd уже какой год пишется. ПОКА это мёртвая идея. О чем блестяще написал Линус в своей книжке "Just for FUN" и доказывает применение комбинированных подходов в NT - чай, там не дураки сидят.
 

C3Man
9 May 2002 10:30 PM
даа... начали с чего? про С# один miroh шота сморозил... чем тебе делегаты ненравятся то??

C# нормальный новый язык...как для первой версии - ваще супер. Я вот вспоминаю убожеский Delphi 1 или первую жабу... и ненадо говорить что С# это копия чегото там. Жаба тоже вышла из сишки ...

и еще - ненадо путать С# и .Net Framework...
 

glassy
10 May 2002 1:52 AM
имхо Ди уже есть -- похож на Си только с gc
 

Se
10 May 2002 12:17 PM
2glassy: "имхо Ди уже есть -- похож на Си только с gc"
Можно ли узнать ссылочку?
 

Наблюдатель
11 May 2002 12:31 AM
2Se
Небольшая ремарка, уважаемый, вы знаете какая точность у обычных, бытовых, GPS приемников?:) Да и попробуйте где-нибудь внутри здания поймать сигнал хоть одного спутника:))) Самое удобное место это высотная крыша:), а теперь представьте сколько контор с серверами могут жить в высотном здании:))) Вам бы книжки фантастические писать:), вроде того: "инопланетяне убрали силу трения, поэтому у автомашины крутились колеса, но она стояла на месте":)
 

Anti-MS
11 May 2002 8:28 AM
http://www.digitalmars.com/d/
Вот он Ди.
Впрочем для меня оно начнет существовать только тогда (если) будет частью GCC.
 

eXOR - billgmicrosoft.com
11 May 2002 7:53 PM
2 Se:
Кхм... присоединяясь к me, Qrot'у и Наблюдатель, хочу еще спросить:
1) кто же за это "счастье" платить будет.
2) как жа вы хотите всех провайдеров поубивать? А не боитесь?
 

eXOR - billgmicrosoft.com
11 May 2002 7:53 PM
2Re:
Был Smalltalk, почему же до сих пор нет 100% объектной OS?
 

me - userinternet.com
12 May 2002 12:55 AM
>> почему же до сих пор нет 100% объектной OS?
Мне вот тоже интересно:))) Может, никому не надо?
 

glassy
12 May 2002 1:39 AM
2me&eXOR: MS тут совершенно не при чем со своими медиапроигрывателями :)
 

eXOR - billgmicrosoft.com
12 May 2002 11:05 PM
2 me:
Ну почему же? Может и нужно... просто сделать чтобы оно хоть как - то ворочилось на современном железе будет ох как непросто :-).

2 glassy:
Чей - то он меня не впечатлил... хотя подобного рода языки мне нравятся :-(.
 

RoN - rodionlenta.ru
13 May 2002 1:08 AM
Кто даст определение "объектно ориентированной OS" ?
 

eXOR - billgmicrosoft.com
13 May 2002 1:29 AM
2 RoN:
Определенние не дам, но могу сказать что я вкладываю в это понятие.
 

RoN - rodionlenta.ru
13 May 2002 2:13 AM
2 eXOR: Интересно было бы услышать. Вовсе не для флейма.
 

Skull - sibskullmail.ru
13 May 2002 5:04 AM
2eXOR: "почему же до сих пор нет 100% объектной OS?" - об этом грамотно рассказал Линус в споре с создателем Minix. Затраты производительности на межобъектные взаимодействия микроядра (а не это ли базис для полностью объектной ОС?) резко уменьшают общую производительность по сравнению с монолитными ядрами. Из книжки "Just for FUN".

2RoN: я тут подумал и написал свое определение (которое, естественно, не канает на истину в последней инстанции) в ответе eXOR.
 

RoN - rodionlenta.ru
13 May 2002 9:33 AM
2 Skull: Ну а если взаимодействие между процессами в микроядерной ОС не межобъектное? Что это как-то сильно может повлиять на производительность? Микроядро, имхо, с объектностью вообще не связано никак.
 

Qrot
13 May 2002 9:56 AM
2Skull: ну так в том что касается микроядра твой Линус не совсем прав - поищу ссылочки, там микроядерный линукс (переделанный) вполне достойно выглядит в сравнении с монолитным.
 

Qrot
13 May 2002 10:56 AM
2Skull: http://www.cs.ucsd.edu/classes/fa01/cse221/papers/haertig-uk ernel-perf-sosp97.pdf
 

PTO - kruchkovkgb.ru
13 May 2002 11:17 AM
2 Skull: я уж было думал, что будет народу стыдно цитировать те места из Жаст фо Фан, где недоученный студент спорит с профессором, который преподает как писать ОС и автором самой любимой книге по этому вопросу как раз, при этом приводя доводы и аргументы, которые уже тогда смешные-смешные были. Да и как объектно-ориентированность ОС связана с микроядерностью ОС не совсем понятно... я все же посоветовать могу все-таки найти книжку Тайненбаума и почитать на ночь... там типа пишут про то как пишут ОС по-работе, а не для фана.
 

RoN - rodionlenta.ru
13 May 2002 12:15 PM
Народ, так что собственно такое "ОО OS", кто скажет? Сильное, просто, подозрение, что это такая же хрень, что и ОО базы данных. Обсуждают их все, а толком, что это такое никто не видел и не знает. Я по крайней мере нигде приемлимого определения не видел.
 

PTO - kruchkovkgb.ru
13 May 2002 12:46 PM
2 Skull: советую перечитать весь тот флейм в оригинале:
http://groups.google.com/groups?q=g:thl697941860d&dq=&hl=en &selm=12595%40star.cs.vu.nl
 

miroh
13 May 2002 12:49 PM
Я все про XML и распределенные вычисления... Например знаю людей, которые рассчитывают нестационарную плазму в мощных плазматронах. Мощности конпов никогда не хватает. Поэтому всегда есть желание обьединить мощности уже имеющихся машин. Покупать новые многокаменные - дорого. Например есть 20 машин - хочется использовать все) Первые эксперименты серьезного успеха не принесли - иногда даже понижение быстродействия. Посчитали затык в 100Мб\с сети. Для полноценной работы прикинули нужно 100Гб\с. Понятно - фантастика. А еще если все в XML. Просто вообще не реально. Процы будут не задачу считать а XML парсить. Про сеть вообще молчу. Так что все это есть странно (c remoting).
Делегаты - уродство, тк не вписываются в идеологию ООП. Торчат из класса как кочерга из арбуза... Посмотрите обработку событий на С# Как говорил профессор Преображенский "Кто на чем стоял?" Идиотичней ничего не видел.
 

Skull - sibskullmail.ru
13 May 2002 2:27 PM
2PTO: где теперь Linux и где Minix? Я подозреваю, что на свете очень много вещей, разработанных по уму. Но побеждают не эти самые идеи, а наиболее приближенные к реалиям. :)
 

Chkaloff
13 May 2002 2:41 PM
2 miroh:
>Я все про XML и распределенные вычисления...
[...]
>Посчитали затык в 100Мб\с сети. Для полноценной работы
>прикинули нужно 100Гб\с.
Ну давайте начнем с того, что не все задачи хорошо поддаются распределению.
При том, что вы написали расчеты про 100Гб/c говорит о том, что
при распределении у вас поток по сети почему-то должен быть гораздо больше, чем сегодня может пропустить шина PCI, быстрее чем работает память и может обработать сегодняшний процессор.

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

eXOR - billgmicrosoft.com
13 May 2002 2:42 PM
2 miroh:
Значит расппараллелили не правильно (не то).
 

PTO - kruchkovkgb.ru
13 May 2002 3:04 PM
2 Skull: это я к "об этом грамотно рассказал Линус в споре с создателем Minix"... не грамотно и не рассказал... как Тайненбаум и сказал - "у меня бы вы на экзамене хороших оценок не получили"... да и Миникс жива... под опенсорс раздается нынче... вторая версия. под 286м работает на ура :)
 

miroh
13 May 2002 3:14 PM
МБ неправильно. Было так - двумерная матрица скоростей концентраций температур .... Каждый комп делает свой расчет - гидродинамику ур пуассона .... потом нужно обмениваться результатами. В принципе при небольшой матрице мно и 5-10 Гб\с. При применении XML сами понимаете этот порог увеличится раз в 5 - там ведь double сплошняком. Ежли еще на парсинг время занимать - вообще кранты. Но это конечно крайний случай. Если посмотреть на распределенные интернет-интранет серверы- то не так все плохо. Но все равно dcom будет работать в разы быстрее soap/remoting.
 

eXOR - billgmicrosoft.com
13 May 2002 3:14 PM
2 RoN:
Дай мне немного времени, а то я попытался нарисовать тебе примерную иерархию, да получается малопонятно, либо слишком большая, а если не большая, то куцая... но если общими словами говорить, то для меня это ОС, которая удовлетворяет условиям:
1) Все является объектом, от устройства, процесса, ядра... до цвета символа в документе: "Херня - мурня.html"
2) Процесс загрузки - это RunTime выстроенние иерархии.
 

RoN - rodionlenta.ru
13 May 2002 4:01 PM
2 eXOR: В том-то и дело, как тогда трактовать понятие "объект" в контексте подобного определения? Я когда пытаюсь представить себе ОО ОС, то прихожу к выводу, что это получается не объектно-ориентированная ОС, а ОС с объектно-ориентированным API, а мне кажется, что это всё-таки не совсем оно.
 

eXOR - billgmicrosoft.com
13 May 2002 4:35 PM
2 RoN:
А когда ОС для нас не являлась API? ОС - с высоты нашего полета - это набор системных вызовов... тут же будет набор объектов вместо них. То же самое в другой обертке.
 

PTO - kruchkovkgb.ru
13 May 2002 5:03 PM
2 eXOR: ну + наследование, события и прочие ОО фишки... да и файлов как таковых тоже нема... все везде объекты.
 

RoN - rodionlenta.ru
13 May 2002 5:11 PM
2 eXOR: Так, просто-напросто, API - понятие растяжимое. В НТе фактически это куча самых обычных либ, которые тем или иным способом делают форвард различным системным сервисам. Никакой принципиальной разницы между, скажем ntdll.dll, gdi32.dll, kernel32.dll и, к примеру mfc**.dll и т.п. нету.
Т.ч. всё равно не канает такая трактовка. Выходит, тогда - взял любую ОС, впихнул туда ОО - либу для доступа к её ресурсам (ха... да хотя бы тот же WMI) - вот тебе и OO OS. Не годится.
 

Qrot
13 May 2002 5:30 PM
2RoN: ИМХО, нельзя говорить об ОО ядре ОС - т.е. говорить можно, но смысла нет никакого :) хотя бы из-того что для user-land от этого никакого толку не будет. так что только API и остается.
 

RoN - rodionlenta.ru
13 May 2002 6:09 PM
2 Qrot: Ну, так, я к тому и клоню. Что за смысл тогда говорить об ОООС. Так, разве что, ради модного термина :-)
 

miroh
14 May 2002 11:44 AM
дыкть может C# обсудим? Я считаю, что язык кривоват и незакончен. Куча "кульных" фич, типа перегрузки операторов преобразования типов..(уже не говорю про события и делегаты). Все сделано заради взаимодействия с бесиком. В общем и все...
 

me - userinternet.com
14 May 2002 12:02 PM
>> Я считаю, что язык кривоват и незакончен
Считай-считай.
 

eXOR - billgmicrosoft.com
14 May 2002 12:27 PM
2 RoN:
Неа. Ты меня не правильно понял. Ну да ладно. Объяснять очень много... я вчера своему приятелю объяснял что я имею ввиду... он сначала примерно так же как и ты говорил, но когда я ему объяснил что имею ввиду - он тоже идеей проникся... хотя объяснять пришлось примерно часа два... греясь под весенним солнышком... прохожие просто шарахались от нас :-).

2 miroh:
Гы...
 

eXOR - billgmicrosoft.com
14 May 2002 12:29 PM
2 RoN:
Если хочешь могу например по аське объяснить... если правда интересно - пиши в мыло. Оно есть тут: w3cdemo.narod.ru.
 

eXOR - billgmicrosoft.com
14 May 2002 12:29 PM
хотя хреновый из меня объяснятель...
 

RoN - rodionlenta.ru
14 May 2002 12:40 PM
2 eXOR: Если что - аську мою можно через тутошний e-mail найти. Он реальный.
 

miroh
14 May 2002 12:43 PM
Я понял - никто с C# не работает. Тогда понятно. Хотя язык то мне нравится. Если бы делегатов убрать - счастье будет. В событиях я понял жестко используют перегрузку оператора + - по моему используют по худшему сценарию - такая каша получается и непонятен порядок вызова и обработка исключений при широкополосной рассылке. В учебнике написано, что порядок неопределен , а ежели гдето исключение- рассылке каюк. В общем мрак - хотя я вижу никому не интересно.
 

eXOR - billgmicrosoft.com
14 May 2002 1:11 PM
2 miroh:
Да ничего имхо супер - рулезного в этом языке нет. В самом по себе. Да и не такой уж он сырой уже.
 

eXOR - billgmicrosoft.com
14 May 2002 1:12 PM
2 RoN:
Нету email'a с такой аськой.
 

me - userinternet.com
14 May 2002 2:26 PM
>> ничего имхо супер - рулезного в этом языке нет
Есть: switch со строковыми константами, например. Мои любимые enum'ы:)) и структуры, которые создаются не в куче, а на стеке, чего в жаве, похоже, я не дождусь.
 

RoN - rodionlenta.ru
14 May 2002 2:27 PM
Вот сама аська : 96457201 :-)))
 

miroh
14 May 2002 3:10 PM
2 me
Дык это мелочи. Зато нет анонимных и локальных классов, ассертов и слабых ссылок. Коллекции бедней опять же.
 

eXOR - billgmicrosoft.com
14 May 2002 3:15 PM
2 me:
И чего из этого нет в том же Object Pascal?
 

Chkaloff
14 May 2002 3:30 PM
2 miroh:
А индексаторы и свойства. Упаковка / распаковка.
 

miroh
14 May 2002 3:45 PM
2 Chkaloff
Я тут ужеговорил - свойства и индексация это действительно здорово. Это и еще перегрузка операторов и переменное количество аргументов функций - действительно преимущество. Про упаковку - распаковку не знаю в чем преимущества перед просыми типами - в Яве есть классы оболочки.... В общем я понял в яву свойства не будут вводить ... к сожалению
 

eXOR - billgmicrosoft.com
14 May 2002 5:05 PM
2 miroh:
> свойства и индексация это действительно здорово.
Не согласен на 100%.

> В общем я понял в яву свойства не будут вводить ... к сожалению
К величайшему счастью.
 

Alex
14 May 2002 6:28 PM
2: eXor

>> В общем я понял в яву свойства не будут вводить ... к сожалению
>К величайшему счастью.

Все таки к сожалению.. видно опыт быстрой разработки _БОЛЬШИХ_
проектов в очень короткие сроки, когда по уму set get не делается :(( просто для того что бы что-то как-то заработало..
когда 70% того что должно быть прайват вынесенно в интерфейс..

через год возвращаться в этот код это звездец, граждане-товарищи..

а самая правильния концепция свойств на на данный момент, как то и не печально, у Borland
 

Nick - nkulykmail.ru
14 May 2002 10:43 PM
2 Alex. А почему печально?
 

me - userinternet.com
14 May 2002 11:10 PM
>> Зато нет анонимных и локальных классов
Не-на-ви-жу! Они меня бесят. Как бесят и "рекомендации" Солнца о том, что если хотите сливать строки - используйте StringBuffer вместо String + String. В компилятор низзя было засунуть что ли? Или вообще отказаться от String + String? А заодно и от примитивных типов...

>> ассертов
ms-help://MS.VSCC/MS.MSDNVS/vsdebug/html/vxtskVerifyingAsse rtionsInManagedCode.htm
Это не то? (ссылка для MSDN.NET)

>> слабых ссылок
Это каких таких слабых? В CLR всяких полно, вроде...:))

>> Дык это мелочи
Это _приятные_ мелочи.

>> К величайшему счастью.
Введут. Обязательно. Вот увидишь.
 

me - userinternet.com
14 May 2002 11:14 PM
>> И чего из этого нет в том же Object Pascal?
Понятия не имею. Я не видел никогда OP. К счастью, наверное:))
 

glassy
15 May 2002 12:52 AM
АПИ определяет сознание :)
 

glassy
15 May 2002 2:37 AM
это было к другой странице :)
 

RoN - rodionlenta.ru
15 May 2002 6:43 AM
class MyClass
{
int GetMyProperty() {...}
void PutMyProperty(int newVal) {...}
public:
__declspec(property(get=GetMyProperty, put=PutMyProperty)) int MyProperty;
};

ОМЕРЗИТЕЛЬНО. Имхо. Руки бы отрывал, и на VB & Delphi отправлял кодировать. Впрочем, я и не видел, чтобы кто-нибудь из плюсплюсников этой фичей в MSVC пользовался, кроме самого MSVC, когда он #import обрабатывает.
 

Qrot
15 May 2002 10:56 AM
2RoN: больше того, я вообще выпервые такое вижу :)) очень омерзительно - С++ Буилдером повеяло...
 

miroh
15 May 2002 11:29 AM
2 me
Вам еще учиться умерять эмоции надо. Мир жесток и несовершенен. Анонимные и локальные классы - большое преимущество - они вносят обьектность даже в линейный код.StringBuffer необходим.почему? - изучайте работу строк в Си. Кстати и в С# есть аналог - StringBuilder.
assert в С# я не нашел
Слабые ссылки - это ссылки, которые ссылаются на не очень нужный обьект. Обьект в общем то нужен но им можно пожертвовать при нехватке ресурсов при работе говносборника. Есть разные степени слабости.
Свойств не будет - будут темплейты - тоже очень здорово.
 

eXOR - billgmicrosoft.com
15 May 2002 12:21 PM
2 me:
Язык используемый, например, в Delphi.

2 Alex:
>set get не делается :(( просто для того что бы что-то как-то
>заработало..
ну написать 4 строчки вместо одной имхо не сложно с хорошим редактором. А ежели вы этого не делаете то:
1. Нарушаете концепции ООП
2. Сами себе могилу роете.

>через год возвращаться в этот код это звездец,
>граждане-товарищи..
О чем и речь.
 

shapkin - shapkinavm.ru
15 May 2002 12:41 PM
2 miroh
Ассерты: System.Diagnostics.Debug.Assert(...)
Слабые ссылки: System.WeakReference
 

miroh
15 May 2002 12:42 PM
2 PTO
А в кратце там чего?
 

miroh
15 May 2002 12:54 PM
2 shapkin
был неправ - извиняйте!
 

me - userinternet.com
15 May 2002 1:05 PM
>> Язык используемый, например, в Delphi.
Я не использую Дельфи.

>> Анонимные и локальные классы
Они меня бесят. Это не преимущество, а нечто, что прикрывает жопу в отсутствие делегатов (а ля указателей на методы). Нисколько не объектно.

>> StringBuffer необходим.почему?
Я-то знаю чем он отличается от String. Мне не нравится факт того, что при декларированном отказе от перегрузки операторов, Солнце само же сделало эту перегрузку в классе String.

>> assert в С# я не нашел
Ищи. Классик называется System.Diagnostics.Debug.

>> Слабые ссылки - это ссылки, которые ссылаются на не очень нужный обьект.
Не видел такого никогда. Обычно мне все объекты нужны, на которые есть ссылки.

>> Свойств не будет - будут темплейты - тоже очень здорово.
Будут и свойства, и темпелйты. Будет ваще зашибись.

>> написать 4 строчки вместо одной имхо не сложно с хорошим редактором
Свойства родились из нежелания писать приставки set и get к полям класса. Дело не в сложности, а в объектно-ориентированном подходе: со свойствами симпатичнее моделька выглядит.
 

miroh
15 May 2002 1:26 PM
2 me
Вы запутались совсем , молодой человек! Делегаты - и есть главное уродство C#. Они совсем не вписываются в ООП. Кочерга из арбуза - вот мое ощущение. В яве все делается классами и интерфейсами - все просто и понятно. А в делегате неявно передается this или ссылка на класс (если делегат статический). А нужно две функции вызвать - два делегата делать? а нужно 5? МБ проще уже обьект передать , как это все нормальные люди делают? В общем уе..ще.
 

Skull - sibskullmail.ru
15 May 2002 1:34 PM
Уважаемые спецы по С# - не для себя прошу, для приятеля.
В общем он спрашивает, где нормальные контейнеры в C#, например, хэши?

Заранее спасибо. Ваш Skull. :)
 

miroh
15 May 2002 1:47 PM
System.Collections.Hashtable - это нормальный контейнер?
 

Skull - sibskullmail.ru
16 May 2002 10:38 AM
2miroh: спасибо!
 

me - userinternet.com
16 May 2002 11:14 AM
>> Вы запутались совсем , молодой человек!
Сам ты запутался, папаша:)). Делегаты в точности повторяют функциональность анонимных классов. И мне они нравятся. К тому же, использовать интерфейсы вместо делегатов тебе никто не запретит: не железячная контора Sun придумала. Хочешь свою обработку событий - пиши. Хочешь использовать готовое - сколько угодно. Не нравится - не ешь.
 

eXOR - billgmicrosoft.com
16 May 2002 11:17 AM
2 me:
> Я не использую Дельфи.
Я тоже, но ты хотя бы знаешь что это такое?

>Дело не в сложности, а в объектно-ориентированном подходе: со
>свойствами симпатичнее моделька выглядит.
Как раз со свойствами и будет нарушенние объектно ориентированного подхода. Сам подумай как один объект может изменять состоянние (которое описывается свойствами) другого объекта? Он может на него воздействовать вообще (т.е. вызвать методы), а уж как это воздействие скажется на воздействуемом, воздействующий знать совсем не должен.
 

miroh
16 May 2002 11:44 AM
2 me
Все правильно - хамство и невежество в одном флаконе! Делегаты это функции обратного вызова с неявной передачей ссылки на обьект. Они не заменят классов никогда, тк класс предоставляет на порядок больше сервиса , чем одна функция. Ну а на самом деле можно просто получить ссылку на обьект вызовом Delegate.Target.
А про StringBuffer и StringBuilder советую почитать в книжках по Java и C#, а то глядишь еще раз не дай Бог в лужу сядете.
2eXOR
По моему свойства очень даже подходят к ООП. Фактически это просто переопределение оператора присваивания. И тут уж фактически воздействующий обьект сосвсем не знает как воздействие сказывается на воздействуемом.
 

eXOR - billgmicrosoft.com
16 May 2002 12:28 PM
> Фактически это просто переопределение оператора присваивания.
Да это оно и есть.

> По моему свойства очень даже подходят к ООП.
Если это свойство такое, как в Obj Pascal или C#, а если просто свойство (блин с терминологией начинается опять путанница), то совсем все это не хорошо.
 

me - userinternet.com
16 May 2002 12:45 PM
>> Я тоже, но ты хотя бы знаешь что это такое?
Знаю.

Про свойства я не согласен, конечно, но пока ничего писать не буду: влом:))

miroh, про делегаты я все знаю. Как и про StringBuffer, к которому претензий никогда не предъявлял. Анонимные классы мне не нравятся. Точка. Также, как и тебе - делегаты.
 

RoN - rodionlenta.ru
16 May 2002 4:29 PM
А про "слабые ссылки" - что за проблема. Сделайте пул объектов, и ведущий указатель, который когда надо берёт объект из пула, а когда надо - возвращает обратно. Строчек 20 кода на С++, который будет полностью реюзабельный.
 

RoN - rodionlenta.ru
16 May 2002 5:04 PM
И вообще, этот ажиотаж, разведённый вокруг шарпа напоминает лоховскую разводку. Почитаешь/послушаешь, так до него, как будто и не знали, что такое веб-сервисы. А сейчас специально посмотрел - второй SOAP Toolkit вышел ещё в июне прошлого года, а первый я уже даже и найти не смог. Ещё вспомните меня - будет с этими сервисами вторая волна доткомов :-)))
 

me - userinternet.com
16 May 2002 9:43 PM
>> Сделайте пул объектов, и ведущий указатель, который когда надо берёт объект из пула, а когда надо - возвращает обратно

Ну-ка напиши-ка 20 строчек, которые будут знать "когда надо"...
 

RoN - rodionlenta.ru
16 May 2002 10:18 PM
Завтра напишу :-))
 

RoN - rodionlenta.ru
17 May 2002 1:06 AM
Девушка не даёт написать - от компа оттащила... :-)

Значит, так. Что-то типа этого.

template<class T> class CPool {
// здесь какая-нибудь реализация.
// зависит от фантазии разработчика
// можно применить разные стратегии управления пулом
...
friend class CPooledPtr<T>;
protected:
T* GetPointerFromPool(void) {...} // пишу длинно
void PutPointerBackToPool(T *pT) {...} // дабы не комментировать
};

template<class T> class CPooledPtr {
// в приватах описываем копирование
// чтобы не копировали.
CPooledPtr(const CPooledPtr<T>&) {}
CPooledPtr<T>& operator=(const CPooledPtr<T>&) {return *this;}
protected:
T *m_p;
static CPool<T> m_sPool; // один пул на всех
public:
// Стандартная реализация ведущего пойнтера
// но с фичей - в конструкторе пойнтер берём из пула,
CPooledPtr() m_p(m_sPool.GetPointerFromPool()) {}
// в деструкторе - возвращаем в пул
~CPooledPtr() {m_sPool.PutPointerBackToPool();}
// И стандартная перегрузка operator->()
T* operator->() const {return m_p;}
};

///
// Юзается вся эта бодяга примерно так:

class CMyClass {
public:
void method1(void) {...};
void method2(void) {...} // и т.д.
};
...
...

void f(void) {
CPooledPtr<CMyClass> obj1, obj2;
obj1->method1(); obj1->method2();
obj2->method1(); obj2->method2();
}
 

RoN - rodionlenta.ru
17 May 2002 1:18 AM
Продолжаю развлекаться.
Другой вариант - я бы сказал, что поизящнее, но с извращением. Писать не стану. Суть такая - создаём и инициализируем массив объектов. При этом в классе конструктор делаем пустой, а operator new() перегружаем, чтобы он просто возвращал указатель на объект из пула. Аналогично - деструктор тоже делаем пустой, и перегружаем operator delete(). Но это уже не с любым классом, как в предыдущем примере будет работать.
 

miroh
17 May 2002 10:25 AM
2RoN
Дык слабые ссылки это совсем другое. Это касается работы сборщика мусора в java/net . То .что вы пишете - пул обьектов. Очень полезный при организации работы коннектов к БД. Но это не слабые ссылки.
 

Qrot
17 May 2002 11:42 AM
2miroh: не понятно, что же это такое все таки, эти слабые ссылки. раньше ты писал "ссылка не очень нужный" объект. это как? :)
вообще не очень понятна нужность сборщика мусора - как я понимаю, он нужен для подчистки не удаленных вовремя объектов, но при грамотной реализации надобности в нем вообще быть не должно.. что скажешь?
 

me - userinternet.com
17 May 2002 11:42 AM
>> можно применить разные стратегии управления пулом
Собственно, меня и интересует "стратегия":)) На 20 строк, желательно.

Но разговор, в общем-то, не об этом, а о слабых ссылках, которые к пулу и правда не имеют никакого отношения.
 

me - userinternet.com
17 May 2002 11:52 AM
>> что же это такое все таки, эти слабые ссылки
Насколько я понял, слабые ссылки нужны для хранения редко используемых и быстровосстанавливаемых (не обязательно, конечно, "быстро":))) объектов. Например, чувствительный к памяти кэш: если обращений к нему много, то его данные сидят в оперативке, а если клиенты пошли курить или смотреть скринсейверы, то все, что накопил кэш можно спокойно похерить.

>> вообще не очень понятна нужность сборщика мусора
Сборщик мусора - это сборщик мусора, дефрагментатор кучи и пул объектов в одном потоке (или в нескольких, но синхронизованных друг относительно друга). Нужность его очевидна, не правда ли?:)) Поясню: не надо писать delete, объекты быстрее создаются и удаляются. Кстати, а что такое "грамотная реализация"?:))
 

miroh
17 May 2002 12:20 PM
Господа С++ники просто не поняли.... В яве и сишарпе нет оператора delete/free Там есть отдельный поток -демон , который отслеживает повисшие обьекты в куче и удаляет их. Программист сам не удаляет ничего из кучи (что иногда раздражает).
 

Qrot
17 May 2002 12:48 PM
2me: имелось ввиду что при "грамотной реализации" нет проблем с мусором - его просто не должно быть.
"не надо писать delete" - не аргумент, извини :)
"быстрее создаются" - ммм... чегойто вдруг? дефрагментатор даст возможность задействовать всю возможную память, но должны быть накладные расходы на синхронизацию с рабочим потоком. тесты есть?
 

me - userinternet.com
17 May 2002 1:05 PM
тест прост. копирайты у Дона Бокса.
C#:
using System;
public class Test {
public static void Main() {
long counter = 0;
while (true) {
Simple s = new Simple();
if ((counter % 10000000) == 0) {
Console.WriteLine(counter);
}
++counter;
}
}
}
class Simple {
public Simple() {
}
}

C++:
#include <iostream>

using namespace std;

class Simple {
public:
Simple() {}
};

void main() {
long counter = 0;
while (true) {
Simple *s = new Simple();
if ((counter % 10000000) == 0) {
cout << counter << endl;
}
++counter;
delete s; // Эта строчка для тех, кто не считает ее отсутствие аргументом: убери ее и все увидишь.
}
}

Разница - в 10 раз. Не меньше.
 

RoN - rodionlenta.ru
17 May 2002 1:05 PM
2 me: >> "Собственно, меня и интересует "стратегия":))"

template<class T> class CPool {
std::list<T*> m_rgPooled, m_rgAllocated;
public:
CPool() {
int i(POOL_SIZE); while(i--) {
T *pT(new T);
m_rgPooled.push_back(pT); }
}
~CPool() {
ASSERT(m_rgAllocated.size() == 0);
int i(m_rgPooled.size()); while(i--) {
delete m_rgPooled.back();
m_rgPooled.pop_back(); }
}
T* GetPointerFromPool(void) {
ASSERT(m_rgPooled.size() > 0);
T *pT = m_rgPooled.back();
m_rgAllocated.push_back(pT);
return pT;
}
void PutPointerBackToPool(T *pT) {
std::list<T*> it = find(m_rgAllocated.begin(), m_rgAllocated.end(), pT);
ASSERT(it != m_rgAllocated.end());
m_rgPooled.push_back(*it);
m_rgAllocated.erase(it);
}
};

Самая примитивная стратегия. Зараннее созданный пул фиксированного размера. Можно ещё десяток придумать, что за проблема?

Насчёт статистики обращений к объекту - решение тоже давно известно и очень типовое. Опять таки - перегрузка оператора operator->() со счётчиком обращений к объекту. При желании можно хоть лог-файл вести, в какие моменты к какому объекту обращались.

2 miroh: Господа С++ники прекрасно понимают, что такое сборка мусора :-)) При желании вполне можно её реализовать и на С++. Имхо, нет никакой надобности, потому что существует куча способов манипулировать с указателями так, чтобы свести вероятность неправильного обращения с ними к пренебрежимо малой величине, при этом совершенно не теряя контроля за созданием и уничтожением объектов.
 

me - userinternet.com
17 May 2002 1:07 PM
Тест - чистая синтетика, направленная на оценку скорости создания объектов. Если в плюсах сделать создание объектов на стеке (что совершенно бессмысленно), то CLR (C#, грубо говоря) все равно обгоняет раза в 2.
 

me - userinternet.com
17 May 2002 1:08 PM
Мощный форум:))
 

me - userinternet.com
17 May 2002 1:08 PM
RoN, уговорил:))
 

eXOR - billgmicrosoft.com
17 May 2002 1:14 PM
2 RoN:
> При желании вполне можно её реализовать и на С++.
А зачем? Оно и так уже есть :-).
 

RoN - rodionlenta.ru
17 May 2002 1:19 PM
2 me: Если уж речь идёт о том, чтобы такты считать, то, имхо вот такое сделает по скорости шарповский код, аки сынка:

class MyClass {
public:
MyClass() {...}
~MyClass() {...}
void *operator new(size_t s, void *pv) {return pv;}
void operator delete(void*) {};
};

void f() {
void *pv = _alloca(sizeof(MyClass));
int n = 1000000;
while(n--) {
MyClass *p = new(pv) MyClass;
p->SomeMethod();
delete p;
}
}
 

RoN - rodionlenta.ru
17 May 2002 1:25 PM
2 eXOR: То, как оно есть в жаве мне не нравится. Тебе, к примеру, не нравится, что MS заставляет пользователей ставить виндозный медиаплеер с виндой, не спрашивая их желания, а мне точно так же не нравится, что разработчики жавы заставляют меня пользоваться сборкой мусора, не спрашивая - нужна она мне или нет.
 

me - userinternet.com
17 May 2002 1:31 PM
>> аки сынка
Ну-ну:))
 

RoN - rodionlenta.ru
17 May 2002 1:44 PM
2 me: Давай меряться письками - пость семпл на шарпе, чтобы можно было бенч по времени сделать. :)))
 

me - userinternet.com
17 May 2002 1:45 PM
>> имхо вот такое сделает по скорости шарповский код
Хм... Между нами, девочками, скажу, что не сделал. Разве что по использованию памяти.
 

me - userinternet.com
17 May 2002 1:45 PM
не люблю бенч по времени:)) Люблю, когда все наглядно.
 

me - userinternet.com
17 May 2002 1:47 PM
на:
using System;
public class Test {
private static Simple ob = null;
public static void Main() {
long counter = 0;
while (true) {
Simple s = createSimple();
if ((counter % 10000000) == 0) {
Console.WriteLine(counter);
}
++counter;
}
}
private static Simple createSimple() {
if (ob == null) {
ob = new Simple();
}
return ob;
}
}
class Simple {
public Simple() {
}
}

Это полный аналог того, что должно было сделать "аки сынка":))
 

miroh
17 May 2002 1:55 PM
да ! Это смешно!
Но еще смешнее свара мду оракулом и мсом по поводу быстродействия их аппсерверов. По моему - все это бредятинка реально C# C++ Java примерно одинаково быстры - проверено уже несколько раз.
 

Qrot
17 May 2002 1:58 PM
2me: ну так считать то нужно создание объектов в С++, а не создание и удаление. у тебя получается что для С# ты считаешь затраты только на создание, при том что удаление все равно делается, но затраты на него не считаются. да еще и вывод на консоль там же... уж не знаю что эти тесты считают но только не затраты на создание объекта. можешь внести изменения в код и представить результаты? у меня под рукой сейчас ничего нет просто - ни фреймворка ни плюсового компилера :)
 

Qrot
17 May 2002 2:00 PM
хех, пока писал еще куча всего появилось :) но все равно RoN прав, нужно делать бенч по времени и без вывода на консоль (не доверяю я iostream'у в скорости)
 

RoN - rodionlenta.ru
17 May 2002 2:11 PM
2 Qrot: me ещё наверное не понял, что в том коде что я запостил вообще не будет ни создания ни удаления :)) Скорее всего, компилер вообще тело цикла при оптимизации уберёт, если не будет вызовов методов и конструктор/деструктор пустыми будут, как у него в классе Simple.
 

Qrot
17 May 2002 2:32 PM
2RoN: :) я только не понял, чего ты его вообще запостил :)) помимо всего прочего, такая перегрузка встречается не часто. интересна (на самом деле) разница для реальных ситуёвин.
 

RoN - rodionlenta.ru
17 May 2002 2:56 PM
2 Qrot: Такая перегрузка в том же самом STL встречается чуть ли не через строку. Я сам очень был удивилён, когда увидел. Там даже operator new(size_t, void*) перегружен на глобальном уровне. В классах ATL СSimpleArray<T> и CSimpleMap<T> тоже используется. Элджер в книге даже название выдумал для неё специальное (точнее - выдумал, кажись, не он, он только позаимствовал у кого-то): "виртуальное конструирование". Идиома, однако :))
 

me - userinternet.com
17 May 2002 3:05 PM
>> me ещё наверное не понял
Я-то понял:)) Потому и сделал создание только одного объекта. Это ты не понял, что цель в том, что нужно сделать _много_ экземпляров.

Бенч я сделаю как-нить в другой раз. Но скажу сразу, что ваши надежды на тормознутость консоли очень и очень наивны. Пока не сделаете быстрый пул объектов в С++, то так и будете "аки сынки". Напомню, что в CLR он _уже_ сделан.

ЗЫ: Да, и еще. Мне очень нравится язык С++. Многие задачи с его помощью выполняются существенно быстрее (например, вычисления), но я никак не могу понять, почему некоторые из С++ программистов не могут признать, что существенную часть их работы уже сделала МС (да даже Сан, хотя жава создает объекты в 4-5 раз медленнее). Никто не пытается забрать пальму первенства по гибкости у С++! Просто _кое-что_ оптимизировано. Понимаете, господа RoN и Qrot?:))
 

me - userinternet.com
17 May 2002 3:09 PM
>> C# C++ Java примерно одинаково быстры
Это мнение компании Sun. В действительности все обстоит иначе.
 

me - userinternet.com
17 May 2002 3:24 PM
>> считать то нужно создание объектов в С++, а не создание и удаление. у тебя получается что для С# ты считаешь затраты только на создание, при том что удаление все равно делается, но затраты на него не считаются

Ну привет:)) Удаление считается тоже. Иначе бы минут через 20 винда бы мне рассказала, как у нее здорово получилось расширить своп файл в отсутствие свободного места на диске.
 

RoN - rodionlenta.ru
17 May 2002 3:28 PM
2 me: Блин... Ну вот же тебе быстрый пул (я уже устал кодить одно и то же):

void *pvPool = malloc(sizeof(MyClass)*POOL_SIZE);
MyClass *pMyClass1 = new(pvPool) MyClass;
MyClass *pMyClass2 = new(pvPool + sizeof(MyClass)) MyClass;
MyClass *pMyClass3 = new(pvPool + sizeof(MyClass)*2) MyClass;
...
...
pMyClass1->~MyClass();
pMyClass2->~MyClass();
pMyClass3->~MyClass();
free(pvPool);

Вообще, разговор я веду вот к чему. Я прекрасно знаю и вижу, что высокоуровневые языки а-ля Жава или Шарп, и даже скриптовые интерпретаторы типа Ж(ВБ)Скрипта имеют свои достоинства, свои преимущества, свою вполне широкую область применения. В этом меня убеждать нет нужды. Просто не надо меня пытаться убедить, как это упорно тот же Сан и его адепты делают (а теперь ещё и МС с Шарпом туда же), что какая-либо виртуальная машина или интерпретатор сделают по скорости нативный код. Хоть подумали бы о том, что говорят. Это вообще всему здравому смыслу противоречит. Это выглядит, как если пытаться убедить кого-то, что он бегать будет быстрее с двухпудовой гирей на шее, если он её у нужного поставщика купит.
 

miroh
17 May 2002 3:28 PM
2 me
Например jdk1.4 merlin делает C# по поиску в Hashtable в 1.2 раза по простому сканированию - свертке с математикой в 1.1 - 1.2 раза. правда отстает в создании обьектов в 1.5 раза и памяти во столько же раз больше кушает. (мб поэтому и отстает). сам не проверял, но при создании dom структуры из xml файла java обгоняет в 2 раза - по сообщениям из англяз форумов. Правда за такие тесты Микрософт может боба сделать - это нарушение EULA
 

Qrot
17 May 2002 3:50 PM
2me: я не пойму, мы что считаем - создание объектов, или создание, удаление и вывод на консоль в одном флаконе? и что собственно дают циклы внизу, если там нет замеров по времени?
 

RoN - rodionlenta.ru
17 May 2002 3:53 PM
2 me >> "Это полный аналог того, что должно было сделать "аки сынка":))"
Это совсем не аналог.
В том, что запостил я, каждый раз, когда получаем указатель снова - это новый объект. Просто размещён он каждый раз в одной и той же зараннее выделенной области памяти. Этак, если как ты, то я вообще могу написать:
MyClass *MakeObject() {
static MyClass *pObj(new MyClass);
return pObj;
}
Вот это будет аналог того, что ты написал.
 

Qrot
17 May 2002 4:00 PM
2me:
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <stdio.h>

struct test_t
{
test_t() {}
~test_t() {}
char data[1024];
};

#define _MAX_SIZE 100000

int main()
{
DWORD dwTickCnt1 = 0, dwTickCnt2 = 0;
test_t *v[_MAX_SIZE];

//sure your uptime < 49 days
dwTickCnt1 = GetTickCount();

for (int i = 0; i < _MAX_SIZE; ++i) {
v[i] = new test_t;
}

dwTickCnt2 = GetTickCount();

for (i = 0; i < _MAX_SIZE; ++i) {
if (v[i] != )
delete v[i];
}

printf("time in msec: %d", dwTickCnt2-dwTickCnt1);

return 0;
}
несколько некузяво, но основную мысль отражает :)
нельзя ли это же перебить на С# и сравнить результаты? причем как 1 с 1-м так и последующие разы. на Р4-1.4-256-ХР результаты такие - 1-й = 1515, 2-й = 187, 3-й и далее = 171 msec
 

RoN - rodionlenta.ru
17 May 2002 4:01 PM
Кайф.... Вот это я открытие сейчас сделал.

Differences Between C# Compiler and C++ Compiler Output.
There are no object (.obj) files created as a result of invoking the C# compiler; output files are created directly. As a consequence of this, the C# compiler does not need a linker.

Вот это достоинство... Аж челюсть отвисла. Я сразу вспомнил, как, когда в школе учился, то на Ямахах в Бейсике программировал. Накодировал, тут же запустил, ни компилять, ни собирать не надо. Удобно. Ничего не скажешь...
 

Qrot
17 May 2002 4:05 PM
2RoN: ну да у stl есть глобальная перегрузка new и delete но она сводится к тем же самым вызовам malloc/free и констрктора/деструктора. перегрузка подобная твоей IRL все таки редки да и к тесту тоже слабое отношение имеют ИМХО - речь то о выделении памяти в куче.
 

RoN - rodionlenta.ru
17 May 2002 4:17 PM
2 Qrot: А это что ??? :-)))

inline void *__cdecl operator new[](size_t, void *_Where) _THROW0()
{// construct array with placement at _Where
return (_Where);
}

Я же говорю, можешь поверить, я в этом ковырялся. В STL используется постоянно. Именно для той цели, что и я ниже использовал : создание объекта по зараннее определённому адресу, чтобы лишний раз не выделять/освобождать память.
Не веришь - посмотри реализацию std::vector или std::string - именно таким образом манипулирует.
 

RoN - rodionlenta.ru
17 May 2002 4:20 PM
Немного не то запостил. Хотя одно другое дополняет:
inline void *__cdecl operator new(size_t, void *_Where) _THROW0()
{return (_Where);
}
 

eXOR - billgmicrosoft.com
17 May 2002 4:21 PM
2 RoN:
> То, как оно есть в жаве мне не нравится.
Я про плюсы говорил.
 

eXOR - billgmicrosoft.com
17 May 2002 4:22 PM
2 RoN:
>Тебе, к примеру, не нравится, что MS заставляет пользователей
>ставить виндозный медиаплеер с виндой, не спрашивая их желания,
Не поверишь... мне пофигу. :-)
 

RoN - rodionlenta.ru
17 May 2002 4:23 PM
А вообще, я уже и забыл с чего всё началось. По-моему кто-то сказал, дескать, вот как шарп быстро объекты создаёт, быстрее чем С++. Ну я и написал, как в С++ можно максимально быстро объекты создавать.
А если речь идёт за кучу, так зачем надо именно создание объектов измерять, а не malloc/free ?
 

RoN - rodionlenta.ru
17 May 2002 4:28 PM
2 eXOR: Да, честно говоря, я в плюсах готовой сборки мусора не видел. Может, разве, в каких-то либах специальных есть с которыми я не работал. Смарт-пойнтеры или подсчёт ссылок, это не сборка мусора, всё-таки. Впрочем, если горит, можно у Элджера из книги код спионерить :)
 

eXOR - billgmicrosoft.com
17 May 2002 4:30 PM
2 RoN:
Именно в либах... причем их просто до....
 

eXOR - billgmicrosoft.com
17 May 2002 4:43 PM
2 RoN:
Хотя имхо он все - равно в C++ нах не нужен. Только развращает.
 

me - userinternet.com
17 May 2002 4:56 PM
>> Ну я и написал, как в С++ можно максимально быстро объекты создавать.
Извини, конечно, но ты показал, как можно повторно использовать память в куче.

>> нельзя ли это же перебить на С# и сравнить результаты?
Я обязательно этим займусь. Возможно, на этих выходных.

>> виртуальная машина или интерпретатор сделают по скорости нативный код
RoN, ты не учитываешь того, что речь обычно ведется о равной трудоемкости. То есть, если средний программист напишет программу на C# и на С++, то в первом случае получится быстрее. Практически всегда. Понятно, что профессиональные программеры придумают много способов оптимизации алгоритма, но они хотят большую зарплату. Даже _много_ большую.
 

Qrot
17 May 2002 5:06 PM
2RoN: ИМХО, ты не совсем прав - для хранения объектов в контейнере (в том же векторе) использует оператор
void *__cdecl operator new(size_t) _THROW1(std::bad_alloc)
который определен в new.cpp как _nh_malloc. и инетерсно не как создается сам вектор (оно один на тысячу объектов) а именно эта самая тысяча объектов которые в нем хранятся.
а началось все с обсуждения нужности сборщика мусора - в качестве аргумента "за" было предъявлено наличие дефрагментатора кучи, что типа должно ускорить создание объекта за счет ускорения операции выделения памяти.
 

Qrot
17 May 2002 5:13 PM
в тесте еще нужно +1 сделать к разнице тиков для полного щастья, хотя и несущественно в данном случае
 

RoN - rodionlenta.ru
17 May 2002 5:24 PM
2 me: >> "ты показал, как можно повторно использовать память в куче."
Ну так, объект ведь создан? С точки зрения клиента - какая разница каким образом он создан и где он размещён ?
Опять-таки, о чём спор идёт - не пойму, о скорости манипуляций с хипом или о скорости конструирования объектов ?
 

me - userinternet.com
17 May 2002 5:34 PM
Про интерпретатор в CLR: программы, написанные на языках .NET (Си-шарп в том числе) никогда не интерпретируются! Они компиляются и запускаются. Это так, для справки.

>> Ну так, объект ведь создан?
Создан, конечно. Но если я другим потоком, который запущен с малым приоритетом, попытаюсь перебрать созданные объекты, то что получу? Правильно - фиг. Так что там с точкой зрения клиента?
Спор идет о скорости создания объектов в куче.

Qrot, про дефрагментарор кучи я пока еще ничего не говорил. Только то, что он есть.
 

RoN - rodionlenta.ru
17 May 2002 5:36 PM
2 Qrot: В STL я так сходу не найду, чтобы тебя убедить в своей правоте - сильно там исходники замороченные. Посмотри в таком случае ATL::CSimpleArray - там сходу видно как объекты размещаются.

Это вот только кусочек оттуда (здесь я его немножко переформатировал, для компактности):

class Wrapper {
public:
Wrapper(const T& _t) : t(_t) {}
template <class _Ty> void *__cdecl operator new(size_t, _Ty* p)
{return p;}
template <class _Ty> void __cdecl operator delete(void*,_Ty*) {}
T t;
};
....
....
void InternalSetAtIndex(int nIndex, const T& t)
{
ATLASSERT(nIndex >= 0 && nIndex < m_nSize);
new(m_aT + nIndex) Wrapper(t);
}
 

RoN - rodionlenta.ru
17 May 2002 5:43 PM
2 me: "Но если я другим потоком, который запущен с малым приоритетом, попытаюсь перебрать созданные объекты, то что получу?"

Ну вот, приехали... Ты вообще всё в одну кучу свалил (блин, сначала написал, потом только увидел, что каламбур вышел). Ну при чём тут какие-то дополнительные потоки с низкими приоритетами? По-моему задача не стояла написать управление памятью с возможностью перебора всех объектов. Это уже совсем из другой оперы. Но, могу сказать, что, если это надо, то в С++ решается тоже вполне стандартным способом.
 

RoN - rodionlenta.ru
17 May 2002 5:53 PM
Создание объекта в куче = Выделение памяти в куче + Инициализация объекта конструктором.

В чём ты считаешь тут Шарп быстрее и продвинутей, чем С++?

Если речь идёт о первом шаге (выделение памяти), то тогда вообще надо говорить не о С++, а либо о WinAPI (HeapAlloc/HeapFree), либо о CRT (malloc/free), либо о COM API (CoTaskMemAlloc/CoTaskMemFree) и т.п.

Если же о втором (инициализация), то вообще не вижу никакого смысла сравнивать. Это тоже самое, что сравнивать на каком языке быстрее, скажем, два числа перемножить.
 

me - userinternet.com
17 May 2002 5:58 PM
>> на каком языке быстрее, скажем, два числа перемножить
Это я пока не сравниваю
 

RoN - rodionlenta.ru
17 May 2002 6:09 PM
2 me: >> "Это я пока не сравниваю "
Так, объясни же, наконец, _ЧТО_ _ТЫ_ _СРАВНИВАЕШЬ_ ????!!!
Мы вдвоём уже полдня от тебя не можем добиться ответа...
 

Qrot
17 May 2002 6:11 PM
2me: дефрагментатор хоть как то мог повлиять на скорость создания объекта в куче, если ты не его имел ввиду, тогда с какой радости вдруг скорость создания у шарпа выше?
я таки добрался до фреймворка может еще успею сюда результаты запостить.

2RoN: враппер враппером, но ты посмотри как он используется - только в функции SetAtIndex при присваивании в уже выделенную память. а!.. дошло типа :) ну да, похоже на то что ты прав...
 

Qrot
17 May 2002 6:13 PM
нет, не успею :))
 

me - userinternet.com
17 May 2002 6:33 PM
Да ты не кричи:))
Объясняю: сборщик мусора включает в себя пул объектов. _Готовый_, причем. Я пытаюсь показать, насколько он эффективен.
 

RoN - rodionlenta.ru
17 May 2002 7:00 PM
Так а сравнение чего с чем?
Сборщика мусора который есть в C# и сборщика мусора, которого нет в С++?
Сборщик мусора и пул объектов - это самоцель?
Или это всё-таки средство достижения определённых целей?
Если средство, то тогда надо сравнивать не существующее с несуществующим, а определить, что за цель необходимо достичь и сравнивать полученные результаты по конкретным выбранным параметрам в комплексе (скажем, быстродействие, объём кода, затраты памяти, время на разработку, жадность девелоперов и т.п.).
 

RoN - rodionlenta.ru
17 May 2002 7:05 PM
Т.е., скажем, стоит задача 1000000 раз создать объект определённого класса, который, после создания уходит из области видимости (при этом уничтожается или уходит в пул, или ещё что-либо делает - остаётся на усмотрение разработчика). При этом вся память после окончания работы программы должна освободиться, чтобы не было утечек. Критерий сравнения - скорость работы программы.

Такое сравнение устроит ?
 

me - userinternet.com
17 May 2002 7:15 PM
>> Так а сравнение чего с чем?
Уже существующего пула объектов и любого другого, который ты напишешь за то время, пока я напишу new Simple() в цикле.

>> при этом уничтожается
C++ и C# работают одинаково быстро (цифры приведу потом как-нибудь)

>> ещё что-либо делает
C++ сосет. В десять раз. Но, тем не менее, можно написать свой пул, который, возможно, будет лучше. Не забудь только подсчитать временные затраты на написание такой фичи.

Меня устраивает любое сравнение, если тестеры не упираются рогом во что-то одно. RoN, ты не замечал, что мы с тобой говорим о несколько разных вещах?
 

RoN - rodionlenta.ru
17 May 2002 7:18 PM
Опять-таки. Повторяюсь. Зачем тебе нужен пул? Просто чтоб было?
 

RoN - rodionlenta.ru
17 May 2002 9:05 PM
Не знаю, может я чего и накосячил в коде. Если кто заметит - скажите.

1. На Шарпе:
class MyClass {}
class Test {
public static void Main() {
int n = 1000000;
DateTime dt = DateTime.Now;
while(n-- > 0) {MyClass obj = new MyClass();}
TimeSpan ts = DateTime.Now - dt;
Console.WriteLine(ts.Ticks/10);
}
}

2. На плюсах.
class MyClass {};
int main(int, char**) {
int n = 1000000;
DWORD tc1 = GetTickCount();
while(n--) {MyClass *pObj = new MyClass;
delete pObj;}
DWORD ts = GetTickCount() - tc1;
printf("%d\n", ts);
return 0;
}

Результат такой. Обе сборки релизные. Athlon-900,RAM 512M,WinXP.
Шарп: 20028 ms;
Плюсы: 450 ms;

Первоначально было желание попробовать на разных количествах повторов и разных размерах объекта. Один раз запустил, посмотрел, и - не стал.

Хорошо работает пул объектов в Шарпе.
Просто реактивно. :-)))
 

me - userinternet.com
18 May 2002 12:42 AM
Console.WriteLine(ts.Ticks/10);

Ничего личного, RoN:)), но эта строка демонстрирует твое невежество. Фигня в том, что наносекунды - это 10Е-9, а миллисекунды - это 10Е-3... Намек понимаешь или дальше объяснять?
 

me - userinternet.com
18 May 2002 12:44 AM
>> Зачем тебе нужен пул?
Если честно, мне нужен не пул, а объекты, которые он генерит. Причем мне нужны _все_ объекты.
 

RoN - rodionlenta.ru
18 May 2002 9:07 AM
2 me: Я прекрасно знаю что такое нано, а что такое микро (у меня образование - физфак).

"The smallest unit of time is the tick, which is equal to 100 nanoseconds." - т.ч. Ticks, если верить документации - это время в сотнях наносекунд, а не в наносекундах, потому и делить надо на 10, а не на 1000.

В любом случае, говорю же, это первая прога что я написал на Шарпе (до этого за него даже не садился), т.ч. если найдёшь какие-то косяки в ней - то прийму это вполне спокойно.
 

RoN - rodionlenta.ru
18 May 2002 9:09 AM
2 me: Ну а скажи тогда, какая тебе,по большому счёту,разница - из пула генерятся объекты или каким-то другим способом. Они что от этого разные? (пытаюсь постепенно подвести тебя к мысли - зачем вообще используют пулы объектов)
 

RoN - rodionlenta.ru
18 May 2002 9:18 AM
2 me: Хотя, погоди, впрочем ты прав, с этими делениями я что-то совсем запутался. Убедил. Надо и вправду ещё на 1000 делить :-))

Получается, и вправду Шарп быстрее объекты создаёт.
Но, на самом деле это показывает, просто, что у него стратегия управления памятью работает быстрее чем та, которой пользуется CRT по _умолчанию_.

Но, вот в чём фишка, в плюсах я не обязан использовать именно то управление памятью что даёт CRT - операторы new и delete в плюсах - это такие же библиотечные функции как malloc и free и никто не заставляет пользоваться именно ими. В реальной проге я бы никогда не стал 1000000 создавать и уничтожать объект, как я это делал в примере ниже.
 

me - userinternet.com
18 May 2002 9:46 AM
>> Но, на самом деле это показывает, просто, что у него стратегия управления памятью работает быстрее чем та, которой пользуется CRT по _умолчанию_.

Это я и хотел доказать тебе и Qrot'у:)) На следующем этапе попытаюсь показать, что стратегия в CLR достаточно хороша и стремление оптимизировать ее в плюсах неоправданно: либо приходится переходить к частным случаям (можно же выделить сразу sizeof(Simple) * 1000000, а потом просто раздать указатели), либо это не дает никакого выигрыша (тот пример с одним и тем же местом для объектов показал, что плюсам чего-то не хватает все-таки).

>> какая тебе,по большому счёту,разница - из пула генерятся объекты или каким-то другим способом.

Как ты правильно заметил, важна стратегия выделения памяти, а не сам факт наличия пула. Видимо, ранее я выразился несколько некорректно. Однако я почему-то уверен, что в CRT нет никакого пула. Как и стратегии.

>> зачем вообще используют пулы объектов
Для того, чтобы два раза одно и то же не создавать. Так происходит в CLR (по-моему): создается несколько первых объектов, после чего понимается, что они не нужны никому и следующие указатели смотрят на них, а не на новую память. К тому же при старте программы выделяется кусок памяти, который облегчает "создание" тех первых объектов.

>> Но, вот в чём фишка, в плюсах я не обязан использовать именно то управление памятью что даёт CRT

Повторяю: С++ - мощная штука. По гибкости с ним мало что сравнится, но я говорю о трудозатратах для достижения бизнес-требований, а не о возможностях.

:))
 

RoN - rodionlenta.ru
18 May 2002 10:27 AM
2 me: Не очень могу понять из твоих постингов, что ты подразумеваешь под отсутствием/наличием пула и стратегии.

Немного поясню упрощённо, как это делается в CRT, и что в этом случае подразумевается под стратегией.
При инициализации CRT запрашивает у ОС сразу непрерывный кусок памяти, чтобы каждый раз не обращаться за памятью к OS. Потом при вызовах new/malloc/delete/free, по опредёлённому алгоритму, CRT выделяет и освобождает блоки внутри этого зараннее выделенного куска (собственно, этот кусок памяти и называется хипом CRT). Этот алгоритм, по которому выделяется и освобождается память и представляет собой стратегию управления памятью. Такая методика работы с памятью является общепринятой, а различные реализации отличаются, как правило, именно стратегией выделения/освобождения памяти в зараннее выделенном хипе. И опять-таки, повторюсь, в С++ всё это работает на уровне библиотек, а не компилятора. Всё это, в случае надобности, поддаётся перегрузке и замене на свою реализацию. Например ATL при сборке с опцией ATL_MIN_CRT заменяет её своей, чтобы можно было выкинуть startup код CRT, MFC в дебаг-сборке перегружает ф-ии управления памятью для обнаружения memory-leaks и т.п.

Дополнительную информацию, если кому интересно, то можно найти у Элджера (что касается C++) и у Кнута (что касается стратегий управления памятью вообще)

BTW, переписав код что был ниже с перегрузкой new получил быстродействие, которое не смог измерить по причине недостаточной разрешающей способности GetTickCount. Т.е. результат < 1 ms.

А насчёт стратегии CLR, то сдаётся мне, что он просто оптимизирует выделение памяти за счёт того, что ему заранее известны размеры блоков, которыми она может запрашиваться. Кстати, у Элджера рассматривается в числе многих и такой вариант оптимизации - разбить хип на отдельные сегменты, для того, чтобы в каждом сегменте размещать объекты одного и того же размера - это очень сильно упрощает и ускоряет алгоритм работы с памятью.
 

me - userinternet.com
18 May 2002 11:10 AM
Ок.
 

glassy
19 May 2002 3:50 AM
10e-9 или 1e-9?
у меня образование не физфак, а немного более floatdouble

:)

товарисчи линуксоиды, а malloc/free ждет тиков ядра в линуксе или как?
 

me - userinternet.com
19 May 2002 7:14 PM
>> 10e-9 или 1e-9?
1e-9, конечно:)) "Фигню-с сморозил-с" (с)
 

RoN - rodionlenta.ru
19 May 2002 11:25 PM
2 me: Продолжение сабжа. Старые письки меряются на новый лад :))
Итак. Выделение более-менее _произвольных_ блоков памяти.

1. Код на шарпе:
public static void Main()
{
DateTime dt = DateTime.Now;
int[] rgn;
int n = 10000;
while(n-- > 0) rgn = new int[n];
TimeSpan ts = DateTime.Now - dt;
Console.WriteLine(ts.TotalMilliseconds);
}

2. Код на плюсах:
int main(int, char**)
{
int n = 10000;
DWORD tc1 = GetTickCount();
while(n--) {
int *rgn = new int[n];
delete[] rgn;
}
DWORD ts = GetTickCount() - tc1;
printf("%d\n", ts);
}

Результаты:
1) При n = 10000:
шарп = 120 ms
плюсы = 10 ms
2) При n = 100000:
шарп = 71673 ms
плюсы = 121 ms
3) При n = 1000000:
плюсы (была ещё вставлена проверка что память выделяется успешно) = 21150 ms
шарп = принял ванну, попил кофе, выкурил сигарету, перечитал главу из Дейта - после этого нажал Ctrl-C...

Может я опять чего-то накодил не так ?
 

Qrot
19 May 2002 11:54 PM
2RoN: угу, здесь мы круты :)) ИМХО, дело в следующем - для создания объектов в шарпе выделяется заранее кусок кучи, и отдается на растерзание пресловутому пулу объектов/сборщику мусора и что там еще в одном флаконе. выделение памяти и работа с ней напрямую не вписывается в работу пула (да и в идеологию языка), отсюда и такие накладки. думаю, если провести тест на массиве объектов, как я раньше писал - то получим выигрыш у плюсов. только массив должен быть большим, что бы происходила реаллокация блока памяти, отведенного под пул объектов в шарпе. и еще - есть подозрение что сборщик мусора в шарпе пока суть да дело по-тихому удаляет созданные объекты и на их месте создает другие, в плюсах ясень пень каждый объект создается заново.
 

miroh
20 May 2002 9:09 AM
2 RoN
Про старые тесты. В С++ вы каждый раз убираете обьект а в шарпе этого не происходит - все повисшие обьекты зараз потом убирает сборщик мусора , когда сам захочет или когда программа заканчивается. Попытайтесь -если интересно смоделировать это. МБ определите массив обьектов, создайте их а потом весь массив разом убейте delete[] - так думаю корректней будет.
 

Qrot
20 May 2002 11:20 AM
еще один тест, вернее три :)

1)
//test-c++.cpp

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <stdio.h>

class test_t {
};

int main(int, char**) {

test_t *p;

ULONGLONG ll1 = 0, ll2 = 0;
SYSTEMTIME st1, st2;

GetSystemTime(&st1);
p = new test_t [100000000];
GetSystemTime(&st2);

SystemTimeToFileTime(&st1, (LPFILETIME)&ll1);
SystemTimeToFileTime(&st2, (LPFILETIME)&ll2);
DWORD ts = (DWORD)(ll2-ll1);

printf("%d\n", ts);

delete [] p;

return 0;
}
 

Qrot
20 May 2002 11:21 AM
2)
//test-c#.csh

using System;

class Test {
}

class _ {

public static void Main() {
DateTime dt = DateTime.Now;
Test[] p = new Test [100000000];
TimeSpan ts = DateTime.Now - dt;
Console.WriteLine(ts.Ticks);
}
}
 

Qrot
20 May 2002 11:22 AM
3) - старый от RoN c С#, передалнный на вывод тиков
using System;
class MyClass {}
class Test {
public static void Main() {
int n = 100000000;
DateTime dt = DateTime.Now;
while(n-- > 0) {MyClass obj = new MyClass();}
TimeSpan ts = DateTime.Now - dt;
Console.WriteLine(ts.Ticks);
}
}
 

Qrot
20 May 2002 11:24 AM
результаты:
1) 0
2) 241406250
3) 20312500

ы? :))
 

Qrot
20 May 2002 11:45 AM
вдогон: при увеличении кол-ва объектов до 100000000 тест №2 генерит exception, а на плюсах все замечаельно.
 

Qrot
20 May 2002 11:45 AM
вдогон: при увеличении кол-ва объектов до 100000000 тест №2 генерит exception, а на плюсах все замечаельно.
 

Qrot
20 May 2002 11:45 AM
вдогон: при увеличении кол-ва объектов до 100000000 тест №2 генерит exception, а на плюсах все замечаельно.
 

Qrot
20 May 2002 11:45 AM
вдогон: при увеличении кол-ва объектов до 100000000 тест №2 генерит exception, а на плюсах все замечаельно.
 

Qrot
20 May 2002 11:45 AM
вдогон: при увеличении кол-ва объектов до 100000000 тест №2 генерит exception, а на плюсах все замечаельно.
 

Qrot
20 May 2002 11:45 AM
вдогон: при увеличении кол-ва объектов до 100000000 тест №2 генерит exception, а на плюсах все замечаельно.
 

Qrot
20 May 2002 11:45 AM
вдогон: при увеличении кол-ва объектов до 100000000 тест №2 генерит exception, а на плюсах все замечаельно.
 

Qrot
20 May 2002 11:45 AM
вдогон: при увеличении кол-ва объектов до 100000000 тест №2 генерит exception, а на плюсах все замечаельно.
 

Qrot
20 May 2002 11:45 AM
вдогон: при увеличении кол-ва объектов до 100000000 тест №2 генерит exception, а на плюсах все замечаельно.
 

RoN - rodionlenta.ru
20 May 2002 12:58 PM
Я написал ещё один, в котором конструктор запрашивает память дорполнительно (это ситуация в которой как раз должен помогать пул - избавлять от оверхеда на дополнительное создание объекта):
1. Шарп:
public static void Main() {
int n = 1000000;
DateTime dt = DateTime.Now;
while(n-- > 0) {
Simple s = new Simple();
}
TimeSpan ts = DateTime.Now - dt;
Console.WriteLine(ts.TotalMilliseconds);
}
class Simple {
int[] m;
public Simple() {
m = new int[1024];}
}

2. Плюсы:
class Simple {
int *m;
public:
Simple() { m = new int[1024];}
~Simple() { delete[] m;}
};

int main(int, char**){
void *pv = _alloca(sizeof(Simple));
unsigned int n = 1000000;
DWORD dwTicks = GetTickCount();
while(n--) {
Simple *pObj = new Simple;
delete pObj;}
DWORD dwSpan = GetTickCount() - dwTicks;
printf("%d\n", dwSpan);
return 0;
}

И снова шарп отсосал со счётом:
5593 : 1703
К тому же этот тест скорее всего не учитывает часть затрат на сборку мусора. Если учесть - то отсос получится, имхо, более смачным.
 

eXOR - billgmicrosoft.com
20 May 2002 3:16 PM
2 RoN && Qrot:
Да растерзали, как тузик тряпку :-). Хотя читать приятно :-).
 

Qrot
20 May 2002 3:27 PM
2eXOR: да дело не в растерзали... надо ж понять как этот сборщик работает и вообще нафиг оно надо. получается что не надо оно совсем.
 

RoN - rodionlenta.ru
20 May 2002 3:58 PM
Сборщик надо для того чтобы побольше бывших посудомоек смогли стать "программистами".
 

miroh
20 May 2002 4:27 PM
Сборщик работает примерно раз в 30 сек при нормальной нагрузке на ресурсы. В примере с me видно, что такой подход дает некоторые преимущества.На самом деле сборка мусора работает обычно при простое\уменьшении интенсивности вычислений - это эффективней чем делетить обьекты в самый критически важный момент вычислений.
 

Qrot
20 May 2002 4:32 PM
2RoN: ну ты не прав имхо.. нельзя взять и так всех запросто посудомойками обозвать :)
я хотел что сказать - эффект от сборщика есть при очень малом времени, отведенном на проект, то бишь при лабании. на мой взгляд, участие в таких проектах ничем хорошим не заканчивается - это минус работа, минус здоровье, минус деньги и т.д., поэтому ну его нафиг. а в "нормальном" проекте, когда есть время на проектирование и анализ, сборщик не нужен. тем более если он прирост по скорости не дает нифига.
 

me - userinternet.com
20 May 2002 4:47 PM
>> получается что не надо оно совсем.
Интересный вывод...

http://www.sun.ru/win/developers/std02/index.html
Всем рекомендуется сходить. Особенно на последний доклад: он ожидается самым смешным:))
 

me - userinternet.com
20 May 2002 4:50 PM
Создание больших объектов попробую завтра.
 

miroh
20 May 2002 4:52 PM
2 me
А что там смешного?
По моему все логично. Яву пытаются в утюг впихнуть дык почему же в робототехнику низя? Или уже Net compact продвигать поскорее надоть?
 

miroh
20 May 2002 4:56 PM
Извиняйте - там про производительность.... Дык это только для Java существует масса методов оптимизации - тк платформа открытая, а для NET только то, что Микрософт соизволит предоставить. Считается почемуто, что именно гибкость Явы и дает преимущество в производительности над NET например
 

Qrot
20 May 2002 5:04 PM
2me: ссылки это конечно хорошо, но результаты то ты можешь как то пояснить?
 

Qrot
20 May 2002 5:10 PM
2me: не понял, почему самым смешным?
 

me - userinternet.com
20 May 2002 5:59 PM
>> ссылки это конечно хорошо, но результаты то ты можешь как то пояснить?
Возможно, такой результат из-за того, что int в CLR - объект. Такой же, как и Simple, например. А в плюсах - это примитивный тип. Но точно сказать пока не могу: надо поисследовать немного, а некогда. (впрочем, разок я запустил такой тест... плюсы соснули, конечно, но как-то неуверенно)

>> гибкость Явы
Издеваешься?
 

me - userinternet.com
20 May 2002 6:00 PM
>> почему самым смешным?
Потому что первый метод оптимизации - это "купите еще памяти":))
 

Valeriy - valeriyy2kmail.ru
20 May 2002 6:01 PM
2 miroh:
"Сборщик работает примерно раз в 30 сек при нормальной нагрузке на ресурсы. В примере с me видно, что такой подход дает некоторые преимущества.На самом деле сборка мусора работает обычно при простое\уменьшении интенсивности вычислений - это эффективней чем делетить обьекты в самый критически важный момент вычислений"

Cборщик мусора запускается когда в managed heap заканчивается свободное место, простой тут ни при чем. Подробнее http://msdn.microsoft.com/msdnmag/issues/1100/gci/gci.asp

2 RoN: Проблему производительности нужно рассматривать комплексно, C# не такой уже и медленный, а если сборщик мусора использовать с умом (generation, weak references etc) -- можно добиться приемлемой производительности.
 

Qrot
20 May 2002 6:10 PM
2me: так я ж специально в своем тесте создавал массив _объектов_ а не int'ов! ты результат-то видишь? не знаю какой sizeof у пустого класса в шарпе, можно добить в плюсах до такого же размера - но результат-то не изменится... заметь, это тест именно затрат на создание объекта - память должна выделяться один раз, остальное время тратится на созданеие объекта как такового.
 

RoN - rodionlenta.ru
20 May 2002 6:17 PM
2 me: Если в тесте заменить int на класс, скажем Simple2, то шарп сосёт у плюсов больше чем в 9 раз. Подозрение такое, что ещё накладывается и отсутствие автоматических объектов в шарпе.

2 Valeriy: Если бы мне кто-нибудь на шею гирю повесил, то я бы постарался её снять, а не ломал бы голову над тем как её с умом использовать. Я уже писал, что я не против сборки мусора - эта штука вполне имеет право на жизнь. Я против того, что не остаётся выбора - юзать её или нет. Только и остаётся, что заморачиваться над тем, как её использовать с умом.
 

me - userinternet.com
21 May 2002 12:15 AM
>> Я против того, что не остаётся выбора - юзать её или нет
Ты несколько не прав. В жаве действительно не остается, а CLR поддерживает С++ _тоже_. И та самая первая прога работает так же медленно, как и на обычных плюсах:)).

Я смотрю, производительность - больной вопрос для очень многих:))

ЗЫ: Qrot, я взял твою прогу, уменьшил количество итераций до 100000 и размер создаваемого массива до 100 элементов, и релизные плюсы проиграли дебаговому шарпу... На других параметрах ситуация не в пользу CLR, но все равно не понятно.

ЗЗЫ: Кстати... На П4 CLR работает существенно медленнее, чем на П3...
 

RoN - rodionlenta.ru
21 May 2002 2:28 AM
Сдаётся мне, что этот "managed C++" - такой же кривой изврат, как "attributed С++". Ладно ещё новый язык выдумали, но зачем так корёжить существующий? И что ещё в планах за Windows.Net? У нас теперь как, что-либо без приставки "Net" уже за программный продукт не катит? Скоро, наверное, в магазинах начнут продавать хлеб.net и колбасу.net. Эти деятели со своими "рулезами" всё больше напоминают миссионеров-проповедников. Собирают толпы на стадионах, руками машут, да лозунги выкрикивают. "Web Services - XML - DotNet - Алиллуйя". Какое всё это говно... Надеюсь, что вся эта херня через годик лопнет с треском, как мыльный пузырь, хоть позлорадствовать можно будет :-((
 

eXOR - billgmicrosoft.com
21 May 2002 9:04 AM
2 RoN:
И не надейся. Займет свое место в нише, немного пошатнув Java, Delphi и VB. :-).
 

Valeriy - valeriyy2kmail.ru
21 May 2002 9:37 AM
2 RoN:"новый язык выдумали"
Не новый а дополнили стандартный. А выбор юзать или не юзать остался, посмотрите спецификацию. Вы вполне можете использовать unmanaged секции, там где нужна производительность, эта возможность есть также и в С#. У МС++ очень широкие возможности, при этом никто не мешает программировать в стиле С++.
А .NET, как это не покажется странно, действительно очень полезный продукт, скорость разработки по сравнению с COM в 2-3 раза выше.
 

RoN - rodionlenta.ru
21 May 2002 9:39 AM
2 eXOR: Угу. А к тому времени выйдет какой-нибудь ".Net+", а потом какой-нибудь ".Net XP". Надо же публику модными суффиксами на бабло разводить.
 

RoN - rodionlenta.ru
21 May 2002 9:45 AM
2 Valeriy: Про новый язык я за C# говорил. А "расширениями" своими повсеместными они уже зае...ли. IIS, вон, нарасширяли. Ставишь его, а потом полдня "расширения" эти сносишь - в каждом по триста дыр.
 

miroh
21 May 2002 11:03 AM
в NET фактически один язык - IL. Все эти языки - VB C# managedC++ похожи один на другого. Посмотреть как в квикстарте один пример реализован в разных языках - умиление берет! Кажется только операторы по разному выглядят, а так - различий никаких.
 

Qrot
21 May 2002 11:37 AM
2me: не понял какое кол-во итераций уменьшил?
но объяснить можно так - на больших массивах данных сборщик только мешает, т.к. ему приходится выделять память (что он делает хуже плюсов), а не использовать уже выделенную под уничтоженные объекты. мораль - не использовать большие объемы в подобных языках :)
для клиента подходит, имхо, идеально - .НЕТ в ХР стартует почти мгновенно, размер маленький, гуй делать удобно, работу с сервером тоже, работает быстро... что еще нужно для полного счастья?
 

RoN - rodionlenta.ru
21 May 2002 12:07 PM
2 Valeriy: К примеру, не нравится, что ATL, ради того чтобы выпустить новую её версию, превратили в такое же помоище каким до этого была MFC.
 

Chkaloff
21 May 2002 1:27 PM
2 RoN:
Может я кончно сейчас не очень умную вещь скажу, но почему бы
не протестировать скорость работы следующих вещей в C#:
1) ключ колмпилятора /optimize+
2) на c# реализовать unsafe секцию
3) почему бы не попытаться посмотреть как в C# работают завершители (finalizers)
4) попытаться поколдовать со сборкой мусора (методы System.GC)

Вот.
 

Qrot
21 May 2002 2:05 PM
2Chkaloff: не катит. т.к. поколдовать можно и в плюсах, но в шарпе тогда теряется главное преимущество - простота реализации.
 

RoN - rodionlenta.ru
21 May 2002 2:11 PM
2 Chkaloff: Почему я должен вместо того, чтобы подключать и использовать фичи, которые мне нужны, колдовать над фичами, которые мне не нужны (сборка мусора) с целью устранения их отрицательного эффекта?

В качестве примера (отвлечённого и общего). Мастдай во всей красе. Сегодня включаю комп и на "Welcome screen" вижу надпись "4 unread mail message". Какого, спрашивается, х... какая-то сранная софтина лезет в сеть с моим креденшиалом до того как я залогинился? И какого, спрашивается, х... я должен долбаться, искать где эту фичу отключить, если я её не включал?
 

Valeriy - valeriyy2kmail.ru
21 May 2002 2:43 PM
2 RoN: Колдовать не нужно, можно просто набрать #pragma unmanaged, и сборка мусора Вам не мешает (но и не помогает). Также при создании класса можно указать __nogc, и экземпляры этого класса создаются в обычной heap, и удалять их нужно обязательно, если они не нужны. Так в чем же проблема? Не нравится новый ATL -- используйте старый, или может при установке VS.NET автоматически удаляется VS 6.0?
 

Chkaloff
21 May 2002 3:00 PM
2 RoN:

>Почему я должен вместо того, чтобы подключать и использовать
>фичи, которые мне нужны, колдовать над фичами, которые мне не
>нужны (сборка мусора) с целью устранения их отрицательного >эффекта?
А тем, что 99% процентам программеров на c# со сборке мусора нужно знать только то, что она есть.

А те тесты, которые вы предьявили не отражают реальную картину программирования 99% типовых задач.

При этом сборка мусора (и другие фичи .NET) упрощает и ускоряет процесс программирования.
 

me - userinternet.com
21 May 2002 3:10 PM
>> какого, спрашивается, х... я должен долбаться, искать где эту фичу отключить, если я её не включал?

Ну все, понеслось:(( Жаль, что наши вроде бы профессиональные интересы опять уперлись в "мастдайный" флейм.
По секрету скажу, что в виндах можно сделать с точностью наоборот: сначала _все_ выключено (ну не все: почти все), а потом ты сам че надо добавляешь.
 

me - userinternet.com
21 May 2002 3:13 PM
>> 99% процентам программеров на c# со сборке мусора нужно знать только то, что она есть.
Думаю, сведения о недостатках сборщика мусора тоже неплохо было бы включать в программу изучения языка:)) Хотя мне managed heap очень даже нравится: жава и рядом не лежала по скорости. С++ это все-таки другая песня...
 

RoN - rodionlenta.ru
21 May 2002 3:28 PM
2 Chkaloff: Если доведётся, то сделаю всё от меня зависящее, чтобы ни один из тех 99% программеров, которые знают о сборке мусора только то, что она есть, со мной в команде не работал. Я уже достаточно повидал проектов, которые проходили под девизом "не боги горшки обжигают".

2 me: Ставим XP - по дефоулту включен сервис "wuauserv". Отключаем в свойствах "Mай компутера" автоматическое обновление. Вроде бы отключается, но сервис как запускался автоматом, так и запускается. Гасим сервис - всё остальное продолжает работать нормально.
1) Почему хреновина, которая самостоятельно лазит в сеть, после установки поднята по умолчанию?
2) Почему бы при отключении этой хреновины не остановить сервис?
 

Qrot
21 May 2002 3:30 PM
2Chkaloff: а программы писать этим программерам на шарпе нужно уметь? или умеющие сразу сеньор девелоперами становятся?
ок. тесты, как и любые другие, синтетические. а что отражает реальную картину программирования?
сборка мусора НЕ ускоряет процесс программирования. при хорошем планировании время жизни объекта определяется еще до начала реализации. сборщик же провоцирует на небрежности в отношении работы с памятью и создает иллюзию безопасности, что при привлечении дешевых программеров приводит к увеличению общего времени разработки... ИМХО.
 

eXOR - billgmicrosoft.com
21 May 2002 3:33 PM
2 me:
>По секрету скажу, что в виндах можно сделать с точностью наоборот:
> сначала _все_ выключено (ну не все: почти все), а потом ты сам че
> надо добавляешь.
Не флейма ради, а интересу токмо для... а как это делается?
 

miroh
21 May 2002 3:39 PM
все таки сборщик мусора может дать преимущества, особенно при интенсивных вычислениях. Он срабатывает раз в несколько десятков секунд(по моему опыту) и убирает сразу все обьекты, дефрагментирует кучу. А в с++ уборка происходит на каждый delete причем убирается сравнительно небольшой обьект. Если учесть что gc выбирает время во время простоя(снижения интенсивности вычислений). то преимущества очевидны.
 

Qrot
21 May 2002 3:50 PM
2miroh: не очевидны. потому как по времени вычисления будут занимать на порядок (судя по тестам) больше времени чем без сборщика.
 

me - userinternet.com
21 May 2002 4:00 PM
eXOR, есть такая феня, как Security and Configuration Templates. К сожалению, в виндах слабее .NET Server (у меня была бета 3) по-простому сделать это не получится (хотя нужен-то только один файлик из этого сервера): там все шаблоны настроек какие-то галимые:)) А вот .нет сервер... Там даже звука нет сразу после установки:)) Нужно взять шаблон "Setup security" из дистрибутива .net server beta 3 (или старше - это понятно) и зааплайить на свою тачку. Потом, правда, неделю будешь долбаться в полуработающий комп, но это уже мелочи:))

>> Отключаем в свойствах "Mай компутера" автоматическое обновление.
RoN, насколько я понимаю, сервис автоматического обновления никакого отношения к проверке почты не имеет. Эта идиотская фича появляется сразу после установки паспорта.нет на машинку... Илиу тебя все не так?

>> Почему хреновина, которая самостоятельно лазит в сеть, после установки поднята по умолчанию?
Потому что XP - для простых пользователей, которым недосуг до windowsupdate.

>> Почему бы при отключении этой хреновины не остановить сервис?
А зачем? Мешает что ли?:))
 

me - userinternet.com
21 May 2002 4:02 PM
>> особенно при интенсивных вычислениях.
Вот уж неправда:))
 

miroh
21 May 2002 4:05 PM
2 Qrot
тесты разные бывают... Посмотрите более ранние тестики в этом же треде C# выигрывал. Да и по другим тестам существенных различий нет.
 

Qrot
21 May 2002 4:23 PM
2miroh: более ранние тесты проверяли что угодно только не то что требовалось :)) но даже по ним ясно видно что при больших требования к памяти шрап проигрывает очень сильно.
 

RoN - rodionlenta.ru
21 May 2002 4:31 PM
2 me: Автообновление я по другому поводу вспомнил. А насчёт почты я так и подумал сразу, что это с паспортом связано. Я же виндузятник, всё-таки :) Просто мне ну очень это не понравилось, что мой паспорт станут в инет показывать, просто когда комп включат, даже в моё отсутствие. Так что захерачил я этот паспорт.
 

miroh
21 May 2002 4:34 PM
дак это и понятноно! Когда ресурсы сильно расходуются говносборник начинает интенсивно трудиться. В реальных приложениях такое когда может быть(насоздавать тыщи обьектов)? Всегда что то пула обьектов(ресурсов) делаешь. Я на С++ то же никогда обьектами не разбрасываюсь, а использую многократно,если есть возможность. Вот тут то и будет преимущество проявляться - работает тихо некий демон - говно подчищает\прибирает.
 

Valeriy - valeriyy2kmail.ru
21 May 2002 4:40 PM
2 miroh: "Если учесть что gc выбирает время во время простоя(снижения интенсивности вычислений"
Откуда такая информация, можно ссылочку?

Сравнивать дефрагментацию gc кучи и удаление обьекта из памяти в С++, все равно что сравнивать слона и муху. При каждой сборке мусора проверяются roots, строится граф состояний обьектов, для поиска ненужных, дефрагментируется куча, изменяются значения указателей на поколения, изменяются указатель NextObjPtr, проверяется finalization queue на наличие Finalize и т.д. , а это довольно дорогие операции. При этом многие ресурсы, такие как открытые файлы, соединения, ресурсы ОС приходится освобождать явно, как что особого прироста скорости кодирования не наблюдается.
Хотя приложения с автоматической сборкой мусора эффективнее работают с памятью, за счет ее дефрагментации, чем проложения использующие обычную кучу.
 

miroh
21 May 2002 5:02 PM
так делается в Яве точно совершенно - из литературы знаю и из собственного опыта(просто наблюдал как работает сборщик). Где то читал, что и в нет то же самое - не помню
 

miroh
21 May 2002 5:14 PM
правда вот что прочитал толькочто
In reality, a collection occurs when generation 0 is completely full.
Это для НЕТ. Значит в нет по другому. На самом деле алгоритмов сборки мусора -море. Как для каждого сборщик запускается - вопрос.
 

RIK
21 May 2002 10:04 PM
RoN, Qurot
Забавно вас читать. Уж больно некоторые высказавания по поводу C# напоминают высказывания glassy по поводу C++.
 

RoN - rodionlenta.ru
21 May 2002 11:02 PM
2 RIK: Какие, например ?
 

glassy
22 May 2002 12:41 AM
2Qrot: cheers
2RIK: я называл C++ гирей на моей шее??? :)
 

Qrot
22 May 2002 10:13 AM
2RIK: скажи, мил человек, как можно в слове из четырех букв (пусть даже атинских) сделать ошибку? посмотри как ник пишется.
и собсно, примера хотелось бы.
 

RoN - rodionlenta.ru
22 May 2002 11:22 AM
Аналогия С vs. C++ и C# vs. C++ некорректна. C++ вносит в программирование новые концепции, которых в С нет. C# не вносит ничего нового, кроме как кое в чём упрощает разработку. С одной стороны упрощение _кодирования_ это хорошо. Но практика показывает, что чрезмерное упрощение за счёт переладывания обязанностей на компилятор и рантайм приводит, как правило к созданию иллюзии простоты программирования _вообще_, что неверно и плохо. Отсюда масса совершенно кривых и убогих проектов реализованных на тех же Дельфях и Вижуал Басике.
 

me - userinternet.com
22 May 2002 11:35 AM
"С++ программисты - самые умные люди на планете" (с) Дон Бокс.
 

miroh
22 May 2002 11:42 AM
Но зато некоторые обрезания языка и платформы дают возможность создавать сильную систему безопасности как в Яве. Особенно это важно сейчас. Например представьте вирус в мобильном телефоне или смарткарте... C# правда позволяет побаловаться ...
 

me - userinternet.com
22 May 2002 12:11 PM
>> некоторые обрезания языка и платформы дают
...невозможность создавать гибкие и высокопроизводительные приложения. Систему безопасности можно сделать не в ущерб этим преимуществам.
 

Qrot
22 May 2002 12:12 PM
2miroh: угу, сначала с помощью явы дадим возможность создавать вирусы в мобильниках, а потом скажем, что наша модель безопасности такая крутая, что нам на эти вирусы пофигу :)
 

miroh
22 May 2002 12:33 PM
2 me
Про гибкие и высокопроизводительные приложения - все уже сказано и написано: Java сейчас лидер в этой области, считается, что на ней работают до 80% приложений масштаба предприятия. Мокрософт в смысле безопасности тут тоже отличилась - это общее место. Когда я прочитал,что идеология безопасности ActiveX это доверие к разработчику - я ох....л.
2Qrot
Я не понял мысль совсем... Считается,что ява программы в телефонах будут работать в той же песочнице, что и в браузерах - какие уж там вирусы, записную книжку бы написать...
 

Qrot
22 May 2002 12:53 PM
2miroh: а мысль в следующем - сначала сделаем единую платформу, что бы вирросописатели могли развлечься с как можно большим кол-вом устройств, а потом будем думать как им помешать. если думаешь что на яве нельзя писать вирусы - поищи в Strange Brew
 

RIK
22 May 2002 1:07 PM
2 Qrot.
>как можно в слове из четырех букв (пусть даже атинских) сделать ошибку?
Извини за опечатку в нике. Очень трудно атинские буквы набирать.

glassy >"перегрузка операторов в 99% случаев никому не нужна, виртуальное связывание тоже никому не надо, наследование все резко тормозит"

Qrot >"в "нормальном" проекте, когда есть время на проектирование и анализ, сборщик не нужен."

Qrot >"по времени вычисления будут занимать на порядок (судя по тестам) больше времени чем без сборщика. "

glassy (про примеры на C++, написанные RoN'ом и Qrot'ом)> "Если весь софт для платформы Win написан таким образом, в нем наверняка будет куда больше ошибок, чем у ОС товарищей."

RoN > "Сдаётся мне, что этот "managed C++" - такой же кривой изврат, как "attributed С++". "

RoN > "Сборщик надо для того чтобы побольше бывших посудомоек смогли стать "программистами". "
 

miroh
22 May 2002 1:16 PM
2Qrot
Strange Brew не способен преодолеть песочницу - он может работать только на сервере и только в приложениях, а не в апплетах. Втом то и вся прелесть - песочница кардинально меняет положение с безопасностью. кстати в песочнице может и сервер работать и приложение..
 

Qrot
22 May 2002 1:52 PM
2RIK: извиняю.
по высказываниям есть одно НО: я опирался на тесты, здесь же и приведенные, в отличие от. кроме того, никто не сказал что я не прав, опять же, в отличие от случая с glassy. если считаешь, что я где то ошибся - скажи где. ну и " 21 мая, 2002, 11:37 - Qrot" почитай.

2miroh: не знаю, если честно, чем апплет в данном случае от приложения отличается - если ява будет платформой для приложений. я подозреваю, что там и песочница будет одна всех, включая ОС, с какими-нить хитрыми ограничениями.
впрочем, ява в девайсах для меня вещь не очень понятная и не изведанная (пока еще :)), так что это все только предположения.
 

RoN - rodionlenta.ru
22 May 2002 2:52 PM
2 RIK: managed C++ есть попытка скрестить совершенно разные идеологии программирования - максимальную гибкость и минимум ограничений C++ и простоту и безопасность .Net. Поэтому я и считаю её извратом. Точно так же, как считал бы извратом, скажем, интерпретатор Си (между прочим когда-то давным-давно видел такое чудо).

Attributed C++ - то же самое. Если, я стану, скажем, писать вместо:
class CMyCoClass :
public CComObjectRootEx<CComSingleThreadedModel>,
public CComCoClass<CMyCoClass, &__uuidof(MyCoClass)>,
...
{...}

такое:
[coclass, threading(model=apartment), ...]
CMyCoClass
{... };
То, уж проще, тогда, этот класс на VB 6.0 писать (всё то же самое, только там характеристики COM-класса через птички в свойствах проставляются). Я в общем-то не против VB, но зачем тогда связываться со C++, если ничего от этого по сравнению с VB не выгадываешь?
 

Valeriy - valeriyy2kmail.ru
22 May 2002 3:45 PM
2 RoN: По-моему использование атрибутов проще и нагляднее, в приведенном Вами примере. В МС++ возможны обе формы, и никто не заставляет использовать только одну из них. Да и COM уже медленно но верно становится историей.
 

Qrot
22 May 2002 4:05 PM
2Valery: а что может .НЕТ предложить в пределах одной машины, когда не нужно лезть в сеть и важна производительность? или для "встраивания" в шелл, например. так что COM еще поживет, ИМО.

атирибуты может и выглядят красиво, но это не нативный способ для плюсов - так на кой он нужен, когда есть шаблоны и наследование? там хоть понять можно что в итоге получается, в отличие от.
 

RoN - rodionlenta.ru
22 May 2002 4:15 PM
2 Valeriy: Атрибуты проще и нагляднее, не спорю. Но если мне надо использовать свои классы вместо, скажем IDispatchImpl или CComCoClass? Могу привести вполне реальные ситуации из практики, когда это было нужно и использовалось. Я знаю, что ничего не мешает использовать как аттрибуты так и классы без них, но, смотрится это, на мой вкус, просто ужасно. Думаю, что, всё-таки, должно быть единство стиля при кодировании. Тем более, мне кажется, кто достаточно поработал с ATL, тому CComObjectRoot(Ex), CComCoClass и т.д. настолько привычны, что нисколько читабельности и понимабельности не уменьшают.

COM становится историей? Ну да...
regdmp HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID :)
 

Valeriy - valeriyy2kmail.ru
22 May 2002 5:01 PM
2 RoN: Согласен, в программировании многое зависит от вкуса. На мой взгляд, при разработке COM+ компонентов, например, атрибуты удобны и наглядны. По поводу COM, я же говорил медленно.

2 Qrot: .NET это не только вэб-сервисы, в пределах одной машины он может многое, можно сказать все, и с COM может взаимодействовать, и с API разными. Возникает закономерный вопрос:
А чего же .NET не может в пределах одной машины?
Вопрос производительности тоже очень спорный, пока был приведен только пример по созданию и удалению могих объектов, где естественно сборщик мусора работает медленней. Как показывает практика, произвоительность .NET проложений вполне нормальная, а скорость разработки растет в несколько раз, при этом не в ущерб качеству.
 

1
22 May 2002 5:05 PM
1
 

1
22 May 2002 5:05 PM
2
 

1
22 May 2002 5:06 PM
3
 

1
22 May 2002 5:06 PM
4
 

RoN - rodionlenta.ru
22 May 2002 5:27 PM
Личное мнение. На проекте начиная с определённого размера общая скорость разработки практически не зависит от выбранного средства. Ну, ессно, не считая крайностей типа программирования в машинных кодах :))
 

Qrot
22 May 2002 5:52 PM
2Valery: взаимодействие как организовано? наверняка все через SOAP RPC пашет.. медленно. ну и шелл пока что на коме завязан.
что касается скорости кодирования - то RoN прав, ИМХО.
 

RIK
22 May 2002 11:04 PM
Qrot, RoN

Я сказал _некоторые_ высказывания _напоминают_, а вовсе не "позиции в точности соответствуют". Разумеется, экстремизма glassy у вас нет (этого еще не хватало!) :-)

Теперь по делу. Мне кажется, что C# - это вовсе не язык для бывших "посудомоек". Для "посудомоек" есть VB, и нового языка им не надо (впрочем, они скорее перейдут на VB.NET,чем на C#).
Действительно, на проекте начиная с определённого размера общая скорость разработки практически не зависит от выбранного средства - но это небольшой размер. Начиная с другого определенного размера нарастают проблемы сопровождения и скорость разработки снижается до нуля - и этот максимальный возможный размер разработки _очень сильно_ зависит от выбранного средства. По моим оценкам этот предел для С - порядка нескольких десятков мегабайт исходников, для С++ - сотен мегабайт. Сопровождение таких проектов - это в большой степени искусство делать исправления в коде без полного понимания, как этот код работает - и с этой точки зрения С++ много лучше, чем С. С# с автоматическим сборщиком мусора - шаг в том же направлении. И шаг разумный, даже если придется за него платить производительностью. Кроме того, если даже распределитель памяти в C# работает в 10 раз медленнее, чем new/delete в С++, то в большинстве задач performance hit будет единицы процентов, а не разы.
 

Qrot
22 May 2002 11:52 PM
2RIK: ну спасибо, утешил.

по поводу больших проектов, C# и сборщика - не совсем согласные мы :) в таком проектах на плюсах мы использовали библиотеки с умными указателями, подсчетом ссылок и прочим.. т.е. замена равноценная, если не лучше :) что должно помочь так скорее это наличие _стандартного_ сборщика и _стандартных_ библиотек для контейнеров - но поможет это больше новичкам. (т.е. приведет к быстрой ротации кодеров и к снижении з/п, причем это уже и для ведущих прогов тоже - оно надо? но это так, из области бреда :)) а еще можно с так сказать - с одной стороны человеческий опыт проектирования и умение учитывать нюансы, с другой - тупой алгоритм, расчитанный на типовые 99% задач. вопрос - что лучше? для большого проекта вопрос очень спорный, ИМХО.

по поводу сборщика - в "Введении в C#" пишут что объекты с размером более 20К выделяются не из участка кучи, управляемой GC, отсюда и накладки. как он при этом освобождается память не очень понятно, правда.
 

glassy
23 May 2002 1:57 AM
2Qrot: если ты просишь меня пролистать постинги, то надо бы давать причину, однозначно вескую.

2RIK: разница в смысле -- я призывал использовать С вместо С++, там, где это было бы разумно. Согласись, C++ популярнее C, относительно C++/C#
 

eXOR - billgmicrosoft.com
23 May 2002 8:32 AM
2 RIK:
> С - порядка нескольких десятков мегабайт исходников, для С++ -
> сотен мегабайт.
Гы. Читаем Буча и других классиков, чтобы понять какой это бред.
 

Qrot
23 May 2002 10:14 AM
2glassy: ни о чем я тебя не прошу.
 

Valeriy - valeriyy2kmail.ru
23 May 2002 10:15 AM
2 RoN: Личное мнение, подтвержденное практикой: скорость разработки, модернизации, сопровождения, довольно серьезно зависит от средств разработки, используемых инструментов, библиотек и т.д.
.NET предоставляет разработчику зрелую, архитектурно-грамотно построенную библиотеку класов, достаточный набор стандартный типов, в противовес вариант-совместимым типам в СОМ. Согласитесь, использование исключений более удобно, чем анализ HRESULT. Использованее для работы с BD ADO.NET намного удобнее чем ADO, кода меньше, он более понятен, и возможностей больше. Сборки имеющие версии, возможность подписи, легко переносимы, тоже добавляют список преимуществ. Таких причин можно привести очень много, все они в комплексе и дают существенный прирост производительности. Хотя по обычным примерам из квикстарта это не очень заметно, это сильно заметно в масштабе проекта. Это опыт работы не только нашей команды, но и других.
Я ни в коем случае не считаю .NET "серебряной пулей", панацеей, совершенным продуктом и т.д., просто это очередной эволюционный шаг в разработке ПО. Где-то пол года назад видел серию статей Буча о .NET, преимуществах предоставляемых этой технологией, но ссылку к сожалению не сохранил.

2 Qrot: Почему Вы решили, что алгоритм тупой? Почему Вы решили что алгоритм один?
И наверняка .NET взаимодействует с COM не через SOAP RPC, зачем лишние расходы.
 

RoN - rodionlenta.ru
23 May 2002 10:41 AM
2 Valeriy: Исключения - хорошо. Но не всегда. Упрощают код они, когда стратегия обработки ошибок через ексцепшоны используется везде и всегда. Для того, чтобы не использовать throw/catch в COM есть серьёзные причины. В COM все ошибки обрабатываются через HRESULT именно из-за того, что заранее неизвестно на чём и как будет написан код, который будет вызывать метод, и откуда он будет вызываться. Можно, конечно, в методе и throw сделать, но что тогда будет, если вызывающий код написан, скажем на VB и ничего об плюсплюсных исключениях не знает? К тому же вызов метода и его выполнение могут вообще находится в разных потоках. Серьёзные преимущества исключения дают в том случае, если бросать и ловить их можно на различных уровнях вложенности ф-ий, а иначе, это только загромождение кода. Кроме того, никто не мешает писать для COM интерфейсов враппперы c исключениями, или использовать готовые через #import.

Если не лень - можешь в двух словах сказать, что за преимущества у ADO.Net? А то я его (ADO.Net) ещё вообще не смотрел.
 

RoN - rodionlenta.ru
23 May 2002 10:45 AM
2 Valeriy: > "Я ни в коем случае не считаю .NET "серебряной пулей", панацеей, совершенным продуктом"

Так в том-то и беда, что MS из кожи вон лезет, чтобы всех в этом убедить. Маркетинговые приёмы, достойные не инженеров, а бродячих торговцев...
 

Qrot
23 May 2002 11:06 AM
2Valery: любой алгоритм тупой по сравнению с человеком - понимать нужно в этом смысле. про SOAP RPC внутри одной машины я как раз хотел узнать точно, а ты "наверняка"... вот, ИМХО, _наверняка_ будет SOAP, т.к. это родная для .NET технология.
 

RIK
23 May 2002 12:18 PM
Qrot >в таком проектах на плюсах мы использовали библиотеки с умными указателями, подсчетом ссылок и прочим.. т.е. замена равноценная, если не лучше

В теории так. А на практике - все большие (более 100М исходников) проекты, которые я видел - это сборище разношерстных приемов программирования и многократное дублирование функциональности (естественно, написать заново проще, чем разобраться в уже написанном). Даже если с самого начала будет использоваться библиотека с самыми что ни на есть рулезными смартпойнтерами, через 5 лет окажется, что в одном и том же проекте используются несколько вариантов этих самых смартпойнтеров, да и полно мест, где используется new/delete. Я почти уверен, что в большинстве коммерческих программ есть memory leaks (с которыми все смирились). Если бы все то же самое было написано на C#, ситуация в целом была бы лучше.

eXOR>Гы. Читаем Буча и других классиков, чтобы понять какой это бред.

Сразу видно человека, который знает, что такое _большой_ проект, только по книгам, пусть даже и классиков.
 

eXOR - billgmicrosoft.com
23 May 2002 12:47 PM
2 RIK:
> Сразу видно человека, который знает, что такое _большой_
>проект, только по книгам,
А тож... акромя вас их никто никогда и не делает :-).

> все большие (более 100М исходников)
Сложность и размер проекта _не_ меряется в мегабайтах, равно как и класс программиста :-).

>Если бы все то же самое было написано на C#, ситуация в целом
>была бы лучше.
Нет, нет и нет. Средство разработки - это только средство. Ошибок в C# можно понаделать больше чем в Java, а уж чего умудряются намудрить в Java - это вообще полный абзац :-).
 

RoN - rodionlenta.ru
23 May 2002 1:29 PM
2 RIK: > "Я почти уверен, что в большинстве коммерческих программ есть memory leaks (с которыми все смирились). Если бы все то же самое было написано на C#, ситуация в целом была бы лучше. "

Я почти уверен, что большинство программ на "простом" Дельфи вообще до работающего состояния не были доведены. С этим тоже все смирились. Если бы всё то же самое было написано на "сложном" C++, ситуация в целом была бы лучше.

Это я к тому, что "простота" и "сложность" языка это совсем не то же самое, что "простота" и "сложность" разработки реального приложения на этом языке.
 

Valeriy - valeriyy2kmail.ru
23 May 2002 2:09 PM
2 RoN:"заранее неизвестно на чём и как будет написан код, который будет вызывать метод, и откуда он будет вызываться"
По-этому в .NET и подтянули возможности VB до нормальных языков программирования, а не ограничили другие языки возможностями VB, как в COM. В .NET разрабатывай на чем хочешь -- результат почти одинаковый.
Вызывающий код не всегда может адекватно реагировать на ошибки, и это основное неудобство HRESULT, исключения намного гибче. Потому и приходится писать врайперы, а это дополнительные затраты.

Преимущества ADO.NET в двух словах -- кода намного меньше, его легче разрабатывать, сопровождать. Остальное в msdn. Работа с MS SQL Server оптимизирована, производительность не сравнивал, но по-моему на MS-ном сайте есть сравнения.

Маркетинговые приемы MS тема отдельного разговора, о них можно долго спорить. Пусть они останутся на совести MS. Люди зарабатывают деньги.

2 Qrot:"любой алгоритм тупой по сравнению с человеком" ну это смотря с каким человеком.
 

me - userinternet.com
23 May 2002 2:31 PM
>> "простота" и "сложность" языка это совсем не то же самое, что "простота" и "сложность" разработки реального приложения на этом языке.

Рекомендую оперировать понятиями не "простота и сложность", а "цена и скорость внедрения". Есть, конечно, такие задачи, где не требуется особо торопиться, но так только в России. Остальной мир уже считать научился.

>> уж чего умудряются намудрить в Java - это вообще полный абзац
Ага:)) Временами разогнуться не можешь от смеха:))

RoN, СОМ умрет. Вместе с HKCR\CLSID. Буквально через одну версию виндов, то есть году этак в 2004-2005. Если ты этого не понимаешь, то очень жаль.
 

RoN - rodionlenta.ru
23 May 2002 2:34 PM
1) "ограничили другие языки возможностями VB, как в COM" - не совсем понял эту фразу. А вернее сказать - совсем не понял.

3) "Вызывающий код не всегда может адекватно реагировать на ошибки, и это основное неудобство HRESULT, исключения намного гибче"
а) Универсальная обработка ексцепшенов - не особенность самих ексцепшенов, а свойство рантайма.
б) Что касается (а). Приведу возможный сценарий засады: На 10 уровне вложенности вызовов генерируется ексцепшен, который не ловится ни на одном из предыдущих 9 уровнях (программеры целиком положились на рантайм, про .Net говорить не буду, но для программеров, к примеру, на дельфях это типично). При этом на 7 уровне вложенности произвели некие действия, которые нельзя откатить раскруткой стека. В результате - утечка ресурсов. И мне по приколу было бы посмотреть на тех людей, когда они будут её искать. Т.ч. исключения, равно как и коды ошибок надо всё равно обрабатывать всегда, а не полагаться на обработку по умолчанию.
в) В COM в дополнение к HRESULT имеется IErrorInfo (т.н. COM-exception), который в отличии от C++ного ексцепшена понимается всеми COM-клиентами, написанными с учётом стандартов, и ещё имеет то преимущество, что позволяет обрабатывать ошибку в случае вызова с переключением с нитки на нитку или с процесса на процесс, что C++ный catch() делать не может.

3) "Преимущества ADO.NET в двух словах -- кода намного меньше, его легче разрабатывать, сопровождать."

"Мы написали приложение в пять раз быстрее. Правда, оно почти не работает, но это исправим по ходу сопровождения." - судя по тому что я повидал, такая разработка уже стала стандартом. Что очень печально... :((
 

me - userinternet.com
23 May 2002 2:42 PM
>> В результате - утечка ресурсов.
Только два слова: garbage collector.
Впрочем, тебе он не нужен, это я понял уже:)) Тогда обрабатывай HRESULT.
 

RoN - rodionlenta.ru
23 May 2002 3:01 PM
2 me: Как у тебя GC закроет открытый файл ? освободит семафор ? отконнектит сокет ? остановит дополнительные нитки ?

Мне он и правда не нужен. Я уж лучше буду вручную делать delete, когда мне нужно, чем каждый раз задавать самому себе подобный перечень вопросов. Мне проще следить за временем жизни _одного_ вида ресурсов - объектами, а остальное релизить в деструкторах, чем переложить этот один ресурс на рантайм, зато взамен взять на себя слежку за _десятком_ других.
 

me - userinternet.com
23 May 2002 3:09 PM
>> Как у тебя GC закроет открытый файл ? освободит семафор ? отконнектит сокет ? остановит дополнительные нитки ?

Уверяю тебя, что в моих руках он все сделает правильно.
 

RoN - rodionlenta.ru
23 May 2002 3:14 PM
2 me: Уверять можете своих заказчиков :))) Меня уверять не надо - мне нужно что-либо более конкретное, чем уверения.
 

Qrot
23 May 2002 3:20 PM
2Valery:
> "любой алгоритм тупой по сравнению с человеком" ну это смотря с
> каким человеком.
для любой задачи можно изменить стандратный алгоритм так, что он станет оптимальным, но будет применим только к конкретной задаче - это ясно? другими словами, универсальные алгоритмы не могут быть оптимальными для каждой задачи в принципе - я достпуно объяснил, или нужно повторить?

каким образом в COM ограничиваются возможности С++?
обработка кода возврата и исключения одинаково гибко и одинаково адекватно позволяют реагировать на ошибки, разница в том что исключения позволяют это делать немного удобнее.

2RIK: это уже проблема организации проекта, а не проблема языка. для шарпа тоже можно написать кучу дополнений и использовать то одно то другое. шарп сам по себе не является панацеей от проблем, связанных с поддержкой кода.

2eXOR: по большим проектам лучше читать Брукса :) и еще книжка была по той же теме - "Путь камикадзе, или что_там_еще_не_помню" , забыл автора, про то как выжить в большом (безнадежном) проекте.
 

RoN - rodionlenta.ru
23 May 2002 3:24 PM
2 Qrot: Мне в этой книжке (Э. Йордан) больше всего понравилась тема: "Как определить, когда пора выйти из проекта, чтобы обезопасить свою карьеру" :-)))
 

RoN - rodionlenta.ru
23 May 2002 3:35 PM
2 Valeriy: > "Что значит "полагаться на рантайм" и "обработка по умолчанию"? Необработаное исключение вываливает сгенерировавший его процесс."

Хм... Встречный вопрос: Что значит "исключение вываливает сгенерировавший его процесс". Только без обид, но ты сейчас сказал, мягко говоря, безграмотную вещь. Я не знаю, как это делается в .Net, но в С++ (в Дельфях, как я знаю, и в VB - тоже самое) любое неперехваченное исключение просто-напросто передаётся в одну и ту же функцию, общую для всего приложения. В С++ она реализована в CRT, в Дельфях - в дельфином рантайме, в VB - в бейсинном рантайме и т.п. В плюсах по умолчанию эта ф-ия просто прерывает программу, но, её можно переопределять по своему усмотрению, чтобы она делала что-либо ещё. Я уверен на 100%, что в .Net тоже сделано что-то подобное.
 

Qrot
23 May 2002 3:39 PM
2Valery(про умирающий COM): ну да, мне вобщем следовало бы догадаться что не просто так все.. да и не особо против я что бы он сдох, если на его место нечто лучшее придет. но все равно, пока шелл не будет работать только на .НЕТ, COM хоронить рано.
 

RoN - rodionlenta.ru
23 May 2002 3:40 PM
2 Valeriy: Вдогонку. Не спорю, в приведённом сценарии-засаде сборщик мусора бы помог... Как костыли хромому. Потому что опять-таки, всё упирается в существование ресурсов, момент освобождения которых должен определять разработчик, а не сборщик мусора.
 

RoN - rodionlenta.ru
23 May 2002 3:49 PM
2 Qrot: А... Пошёл этот MS нах... Могильщики херовы. Не пойму, чему все так радуются. Сейчас похоронят COM, а спустя подгода точно так же похоронят .Net, ради ещё какого-нибудь своего "рулеза". Чувствую, что надо на *никсы переползать.
 

Qrot
23 May 2002 4:12 PM
2RoN: ну, об этом я тоже думал :) но пока что с МС прибыльней как ни крути (для меня). а с юнихом - года 1.5-2 должно пройти прежде чем начнешь понимать что там и как крутится-вертится на том же уровне как понимал это в виндах. у меня собсно как раз эти 1.5-2 года начались недавно :) хотя есть другой вариант - переквалифицироваться в аналитики.
ЗЫ: я смотрю ты после ATL7 на MS лютую обиду затаил :)
 

RoN - rodionlenta.ru
23 May 2002 4:45 PM
2 Qrot: Да устал я уже просто переучиваться каждые полгода :)

MS и не виновата. Просто контора-то сугубо коммерческая. Если они, допустим, сейчас вломят кучу денег и выпустят через полгода кучу говна, то они, ведь, всё равно не скажут, что это говно (бабки-то возвращать надо). Скажут, смотрите, парни, это - кульный суперновый рулеззз, за которым будущее, а .Net, это, типа, говно, т.ч. мы его развивать не будем.
 

Valeriy - valeriyy2kmail.ru
23 May 2002 5:12 PM
2 RoN: " по умолчанию эта ф-ия просто прерывает программу" имменно это я и имел в виду, в С++ std::terminate() по умолчанию вызовет abort(), в .NET runtime передает необработанное исключение в debbuger, а если debbuger не прикреплен генерирует событие UnhandledException, если событие не обрабатывается выводится сообщение пользователю и прерывается выполнение приложения.
С освобождением ресурсов частично может помочь RAII (выделение ресурса есть инициализация) или тот же auto_ptr, тогда по возникновении исключения и стек размотается, и ресурсы освободятся, Хотя лучший выход, споймать исключение, освободить руками ресурсы, и регенерировать исключение.

Через пол года .NET не похоронят, его будут много раз улучшать/модифицировать/обзывать новыми громкими именами. Возможно лет так через 5 выпустят что-то концептуально новое, это прогресс, это развитие, это нормально. С++ тоже не такой какой был 10 лет назад.

"каким образом в COM ограничиваются возможности С++?"
да хотя бы вариант-совместимыми типами данных.
 

Qrot
23 May 2002 5:33 PM
2Valery: да вообщем нет, лучший выход это освообождать ресурсы в деструктуре.. при раскрутке все освободится. в шарпе есть некие финалайзеры, аналог деструкторов как я понял, но пользовать их не рекоммендуют. так что придется как RoN говорит, вместо того что бы следить за одним объектом, следить за 10-ю :)

убей, не пойму каких возможностей С++ меня лишает вариант-совместимые типы данных?
 

RoN - rodionlenta.ru
23 May 2002 5:41 PM
2 Valeriy: Variant-совместимые типы данных нужны только:
1) Если нужно реализовывать чистый дисп или дуальный интерфейс (скажем, для использования из скриптовых языков)
2) Если неохота собирать, включать в дистрибутив и регистрировать proxy/stub модули, а хочется заменить это одним тайп-либом, включенным, скажем в виде ресурса в сам COM сервер.

В остальных случаях набор допустимых типов совпадает с сишным.
Если COM-интерфейс предполагается использовать только в С++, при этом не нужен маршаллинг, либо не впадло маршаллинг написать самому (непонятно, только, нах надо), то его вообще не обязательно на IDL описывать, и тут уже ограничений на типы вообще никаких нет. Единственное требование - наследование от IUnknown.

И вообще, намного ли набор встроенных типов C# больше, чем набор Variant-совместимых типов?
 

Qrot
23 May 2002 5:53 PM
2Valery & RoN: возможности плюсов: наследование, полиморфизм, шаблоны, перегрузка etc. как варинт-совместимые типы, кои вобщем то покрывают все что нужно, мешают использовать эти возможности? в .NET, кстати, тоже есть подобные ограничения - например, беззнаковых целых нет в коболе, и поэтому буззнаковые целые не рекоменданны к использованию в шарпе. как это влияет на использование возможностей шарпа? чушь просто.
 

RoN - rodionlenta.ru
23 May 2002 6:02 PM
2 Qrot: Да мне variant-совместимых типов всегда хватало с головой. По жизни, если делал интерфейс, то, по возможности дуальный. Тестировать/отлаживать из VB или из скриптов тогда можно. Удобно, в общем-то.
 

me - userinternet.com
23 May 2002 6:50 PM
Один мой хороший знакомый выдал: "щас критический параметр - время разработки. все. деструкторы идут нах.й". Проснитесь, господа:))
 

Qrot
23 May 2002 7:47 PM
2me: этот параметр всегда был критическим, а упертость отдельных хороших знакомых не может служить основанием для выбора языка разработки.
кстати, я так и не увидел неоспоримых доводов в пользу шарпа... продукт хороший, я не спорю, но просто пока не особо нужный.
 

RoN - rodionlenta.ru
23 May 2002 9:29 PM
Да, кстати, много уже тут было сказано о том какая это передовая и революционная технология .Net, и какой это передовой и революционный язык C#. Но какого-либо внятного объяснения насчёт того что же в них такого передового и революционного так я и не услышал. Каждый раз разговор возвращается к одному и тому же, а именно - сборке мусора. Отсюда делаю для себя вывод, что нихрена нового, интересного и полезного в них нет. Сборку мусора злом не считаю, но на каждый случай где она полезна, имеется случай, когда она только мешает (см. мой постинг от 23 мая, 2002, 15:01).

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

RoN - rodionlenta.ru
23 May 2002 9:32 PM
2 Qrot: "Продукт хороший". Ну и что же в нём хорошего? Всего-навсего ещё один ОО язык программирования, принципиально ничем не отличающийся от других ООЯП.
 

Qrot
24 May 2002 12:33 AM
2RoN: я не говорю что принципиально новый, я говорю "хороший" :) thread-safe контейнерные классы - за одно это можно спасибо сказать. плюс хорошая, если не лучшая производительность в свеом классе. плюс нативная поддержка .НЕТ, которая хошь-нехошь, а силу набирает. плюс куча всяких мелочей, которых я уже не помню... для проектов под .НЕТ подходит лучше чем что бы то ни было, ИМХО.
 

me - userinternet.com
24 May 2002 1:53 AM
>> Каждый раз разговор возвращается к одному и тому же, а именно - сборке мусора
Ты сам всегда разговор сводил к деструкторам и прочей дребедени типа закрытия файлов вовремя. Все твои вопросы относительно немедленного освобождения ресурсов давным давно имеют ответы. Читай доку.

>> Ну и что же в нём хорошего?
Он удобный. Не более того.
 

eXOR - billgmicrosoft.com
24 May 2002 8:35 AM
2 Qrot:
Угу именно "путь комикадзе или как выжить в безнадежном проекте"... у меня после ее прочтенния наступила пора разочарования в больших проектах и в отрасли в целом... хотя вроде сейчас наклевывается одна штучка эдак на полгода - год... и придется опять веровать и пахать - пахать - пахать :-).

2 RoN:
> Чувствую, что надо на *никсы переползать.
Вопрос сложный... вместо COM/DCOM/.NET поимеешь dlopen/CORBA/.NET+еще чего - нибудь... расслабься и отдели программирование за деньги от программирования для удовольствия.. вообще сходи в отпуск, поменяй пару женщин... в общем отдохни как - нибудь... такая уж у нас отросль.. :-(.

2 me:
> Он удобный. Не более того.
В нем есть одно неудобство для меня очевидное... - развращает сильно... попробуй после него (через пару проектов средних) обратно на C++ сесть...
 

RoN - rodionlenta.ru
24 May 2002 8:52 AM
2 me: > "Все твои вопросы относительно немедленного освобождения ресурсов давным давно имеют ответы."

Пока что никто здесь вразумительного ответа не дал. А явное освобождение ресурсов (не в деструкторе) - это решение, но я это хорошим решением не считаю. Конструкторы/деструкторы для того и существуют, чтобы делать какую-либо работу.

2 eXOR: Отрасль, имхо, разложилась уже давно. Я сейчас программированием не занимаюсь, но если предложат, то, наверное, очень хорошо подумаю... и откажусь.
 

Valeriy - valeriyy2kmail.ru
24 May 2002 10:26 AM
2 Qrot: я Ваш спрашивал, что конкретно Вам не нравится в алгоритме сборки мусора, и какой из алгоритмов Вас не устраивает. А в ответ получил общую фразу, что все алгоритмы глупы по сравнению с человеком, и под каждую задачу нужно адаптировать/переделывать существующие алгоритмы.

По поводу ограничений, BSTR это не std::string, unsign отсутствует и т.д., не скажу что они сильно ограничивают, но неудобства добавляют. А если я все же решу использовать все базовые типы IDL -- маршалинг прийдется писать вручную.

2 RoN:" что же в них такого передового и революционного так я и не услышал."
Как Вам возможность подписи компонента strong name, которая практически полностью гарантирует, что никто не сможет подменить компонент?

Как вам возможность Just-in-time (JIT) activation в COM+?

[ObjectPooling(Enabled=true, MinPoolSize=2, MaxPoolSize=5, CreationTimeOut=20000)]
public class TestObjectPooling : ServicedComponent

А само понятие сборки, которую можно скопировать и использовать, без всяких регистраций, разве что в CAG, для совместного использования, при этом новые версии сборок не удаляют старые, dll hell уже в прошлом.

.NET это не только сборка мусора.
 

me - userinternet.com
24 May 2002 10:29 AM
>> Пока что никто здесь вразумительного ответа не дал.
Ты сам его дал: finalize(). То, что МС не рекомендует использовать завершители - чушь. Это Солнце не рекомендует. МС говорит о том, что завершители должны как можно быстрее выполняться, а если нет особой необходимости, то и вообще забыть про них. К тому же, сборщик мусора может быть вызван для какого-то одного объекта (или группы, насколько я понимаю), так что если нужно закрыть файлик сразу - скока хочешь.

>> явное освобождение ресурсов (не в деструкторе) - это решение, но я это хорошим решением не считаю.
Напрасно. По-моему, вот такая стратегия работы с базой очень даже ничего:
try {
Connection c = <Присоединиться к БД>;
try {
<че-нить сделать с базой>
}
finally {
// Прекращаем связь
c.close();
}
}
catch (SQLException e) {
<Нужно только ругнуться, но ничего не закрывать>
}
Называется JDBC. Если поменять названия классов - получится ADO.NET. Честно говоря, я совсем не представляю, каким боком тут деструктор можно впихнуть:))

>> очень хорошо подумаю... и откажусь
Ну ты еще подумай:))))

>> есть одно неудобство для меня очевидное... - развращает сильно...
Да уж, этого не отнять:))
 

Qrot
24 May 2002 11:02 AM
me: какая ж чушь когда в книжке черным по белому и по русски написано - лучше не надо. вечером целиком цитату приведу. если захочешь :) рекомендует конкретно автор книжки "Введение в C#", не знаю, какое отношение он имеет к САН или МС.

2Valery: ИМХО, вполне можно было понять что я говорю не о недостатках конкретного алгоритма, по сравнению с другим алгоритмом. речь шла о том что предпочтительней - полагаться на свой опыт и свои знания при проектировании, либо полагаться на сборщик мусора и другие алгоритмы, встроенные в язык для ускорения разработки.
 

me - userinternet.com
24 May 2002 12:29 PM
Я тебе и сам че хошь приведу:)) Про завершители я именно там и вычитал.
 

RoN - rodionlenta.ru
24 May 2002 12:46 PM
2 me: Сравни вот эти два куска кода, и скажи, положа руку на сердце, который смотрится лучше:

// Первый вариант - закрываем явно
_ConnectionPtr spCon(...);
try {
spCon->Open(...);
spCon->Execute(...);
}
catch(_com_error &e) {
spCon.Close();
}

// Второй вариант - закрывается само в деструкторе
try {
_ConnectionPtr spCon(...);
spCon->Open(...);
spCon->Execute(..);
}
catch(_com_error &e) {
// можно не делать вообще ничего
// закроется само при раскрутке стека
}

Имхо, второй вариант понятнее намного. К тому же в первом варианте надо бы ещё как-то обрабатывать ошибку при конструировании, т.ч. там ещё один try будет путаться под ногами.

Насчёт того кода, что ты привёл, конечно, на вкус цвет приятеля не найдёшь, как говорят, но вложенный try, на мой вкус, это синтаксический кошмар.

И ещё. Как ты будешь делать то что ты написал, если и конструктор и последующие действия могут кидать исключения одинаковых классов? Поясню - тогда в обработчике исключения сам объект будет не виден, т.к. конструирование надо помещать в try-блок. Придётся писать красивый, вложенный try с двумя обработчиками одного и того же исключения. Типа такого:

try {
A a;
try {
a.f(); a.g();
a.Commit();
}
catch(MyError &e) {
a.Rollback();
}
}
catch(MyError &e) {
// ошибка в конструкторе
}

Сдаётся мне, что у тех кому потом с этим придётся работать этот код завоюет один из первых призов :))
 

me - userinternet.com
24 May 2002 1:01 PM
Фигню, впрочем, написал про сборщик мусора для конкретного объекта: так низзя:))
Зато есть магический using для объектов IDisposable:)))
 

Chkaloff
24 May 2002 1:33 PM
2 RoN:
try
{

{
 

Chkaloff
24 May 2002 1:36 PM
2 RoN:

try
{
int n 22 / Zero;
}
catch(DivideByZeroExeption e)
{
...
}
catch(Exeption e)
{
...
}

Catch, перехватывающий DivideByZeroExeption обеспечивает более точное совпадение, поэтому будет выполнен именно он.

Все просто и интуитивно понятно.
 

RoN - rodionlenta.ru
24 May 2002 1:54 PM
2 me: IDisposable - что это ещё за костыль ? :))

2 Ckaloff: Речь вёл я не о том. Представь, что у тебя вместо int какой-либо объект и тебе в процессе обработки ошибки нужно выполнить какие-либо действия с ним. А в твоём коде в блоке catch он виден не будет.
 

RoN - rodionlenta.ru
24 May 2002 1:54 PM
2 Chkaloff: Сорри за ошибку в нике.
 

Qrot
24 May 2002 2:08 PM
2me: во-во, я все ждад, когда обходные пути всплывут..
 

me - userinternet.com
24 May 2002 2:19 PM
>> Сравни вот эти два куска кода, и скажи, положа руку на сердце, который смотрится лучше:

Второй:)) Он эмулирует finally в плюсах:))
 

me - userinternet.com
24 May 2002 2:33 PM
>> IDisposable - что это ещё за костыль ?
Да нашел я феньку пока читал про GC:
using(SqlConnection c = new SqlConnection(что-то там)) {
c.BeginTransaction();
try {
// bla-bla-bla
// a-la c.Commit();
}
catch (SqlException) {
// обработка фигни всякой
// a-la c.Rollback();
}
}
Короче, using говорит компилеру, что надо вызвать Connection.Dispose() в конце блока, синхронизируя тем самым время жизни и "время" видимости. IDisposable - это интерфейс, который Connection должен реализовывать.
 

Qrot
24 May 2002 2:43 PM
2me: ну точно костыль :) что-то типа "мы крутые, деструктуры идут лесом, но мы их все равно используем - аж два разных вида" :)) нет в жизни совершенства
 

me - userinternet.com
24 May 2002 3:15 PM
не два, а три:))
~Simple() {
}

Ничего не напоминает?:))
 

Qrot
24 May 2002 3:19 PM
тем более :))
 

glassy
25 May 2002 1:30 AM
ага, ВАЗ XP :)
 

Qrot
26 May 2002 4:12 PM
glassy, здесь не все курят траву и уж точно никто не курит тот же сорт что и ты.. делал бы скидку :))
 

eXOR - billgmicrosoft.com
27 May 2002 8:07 AM
2 Qrot:
:-).
 

Shadow
29 May 2002 7:05 PM
Так чем это всё от цпп отличается? _в корне_? (я про язык, а не CLI)
 

Qrot
30 May 2002 12:21 AM
2Shadow:
"В процессе работы над C# мы преследовали несколько целей.
* Создать первый компонентно-ориентированный язык в семействе C/C++..." (С) Э. Гуннерсон, "Введение в C#"
короче, почитай :)
 

eXOR - billgmicrosoft.com
30 May 2002 7:57 AM
2 Shadow:
В корне... тем что он придуман в мелкософте, человеком который придумывал Delphi... Ну и пожалуй тем что в нем delete нет и не предвидится :-).
 

miroh
30 May 2002 11:22 AM
Главное в том, что у мелкософта теперь есть в интеллектуальной собственности профессиональный язык(семейства C++). Еслиб сантехники примирились с расширениями явы, то МС просто развивал бы тот язык. Практически вся концепция содрана с java плюс "кульные" примочки, чтоб было как отдличить...
 

eXOR - billgmicrosoft.com
30 May 2002 11:32 AM
2 miroh:
Да нифига... кульных фичек почти нету, а что есть - все лежит в CRL, т.е. к языку как таковому отношенния не имеет.
 

me - userinternet.com
30 May 2002 10:56 PM
>> кульных фичек почти нету
Есть. И много. Но тебе че-то не нравяцца:))
 

Ron - rodionlenta.ru
31 May 2002 7:23 AM
Вот что я вычитал у Т.Арчера:
"Одним из крупных препятствий на заре разработки .Net была необходимость поддержания высокой степени совместимости с Visual Basic. Поэтому решение должно быть полным и прозрачным без изменения семантики самого языка Visual Basic".

Т.ч., если верить Арчеру, то, выходит, что C# - это не есть улучшенный С++. C# - это не улучшенный С++, это Visual Basic c C++ным синтаксисом. Вот так то...
 

eXOR - billgmicrosoft.com
31 May 2002 7:58 AM
2 me:
Ну пропертя, ну что еще - то? Остальные фичи - это CRL.. а мы смотрим на язык без него...

2 Ron:
> без изменения семантики самого языка Visual Basic"
Не... ну это он зря... VB они перефигачили нафиг... как сказал на презентации у нас один мелкософтовец: "я преодолел чувство отвращенния" и попробовал посмтреть на язык... изменнений VB/VB.NET имхо больше чем C++/C#
 

miroh
31 May 2002 9:20 AM
2Ron
Вот это правильно!!! Я сразу почувствовал, что все эти делегаты -эвенты реверанс в сторону бесика. Такого ублюдства в с++ само по себе появиться не могло никогда. Мокрософт осуществила свою бредовую идею - окончательно скрестить VB и C++. Хотя в целом язык очень даже ничего.
 

miroh
31 May 2002 9:20 AM
2Ron
Вот это правильно!!! Я сразу почувствовал, что все эти делегаты -эвенты реверанс в сторону бесика. Такого ублюдства в с++ само по себе появиться не могло никогда. Мокрософт осуществила свою бредовую идею - окончательно скрестить VB и C++. Хотя в целом язык очень даже ничего.
 

miroh
31 May 2002 9:20 AM
2Ron
Вот это правильно!!! Я сразу почувствовал, что все эти делегаты -эвенты реверанс в сторону бесика. Такого ублюдства в с++ само по себе появиться не могло никогда. Мокрософт осуществила свою бредовую идею - окончательно скрестить VB и C++. Хотя в целом язык очень даже ничего.
 

miroh
31 May 2002 9:21 AM
2Ron
Вот это правильно!!! Я сразу почувствовал, что все эти делегаты -эвенты реверанс в сторону бесика. Такого ублюдства в с++ само по себе появиться не могло никогда. Мокрософт осуществила свою бредовую идею - окончательно скрестить VB и C++. Хотя в целом язык очень даже ничего.
 

miroh
31 May 2002 9:21 AM
2Ron
Вот это правильно!!! Я сразу почувствовал, что все эти делегаты -эвенты реверанс в сторону бесика. Такого ублюдства в с++ само по себе появиться не могло никогда. Мокрософт осуществила свою бредовую идею - окончательно скрестить VB и C++. Хотя в целом язык очень даже ничего.
 

miroh
31 May 2002 9:21 AM
2Ron
Вот это правильно!!! Я сразу почувствовал, что все эти делегаты -эвенты реверанс в сторону бесика. Такого ублюдства в с++ само по себе появиться не могло никогда. Мокрософт осуществила свою бредовую идею - окончательно скрестить VB и C++. Хотя в целом язык очень даже ничего.
 

miroh
31 May 2002 9:21 AM
2Ron
Вот это правильно!!! Я сразу почувствовал, что все эти делегаты -эвенты реверанс в сторону бесика. Такого ублюдства в с++ само по себе появиться не могло никогда. Мокрософт осуществила свою бредовую идею - окончательно скрестить VB и C++. Хотя в целом язык очень даже ничего.
 

miroh
31 May 2002 9:24 AM
бл....
Мозилла или форум глючит?
Отправил пост - через секунду алерт Document contains no data
и вот эта вот фигня...
 

Qrot
31 May 2002 10:04 AM
2miroh: это нам знакомо :) попробуй netowrk.http.keep-alive=false сказать в prefs.js, может поможет
 

eXOR - billgmicrosoft.com
31 May 2002 10:10 AM
2 Qrot && miroh:
Пишите баг - репорт.
 

Слопер
31 May 2002 2:09 PM
Да, почитал все постинги. Однозначного мнения так и не сложил. Вроде облегчает C# жизнь, но и развращает одновременно. Вроде удобно программировать, а свободы полной нет. Свобода ограничивается встроенными алгоритмами-облегчителями.

Понял только одно:
всё меньше и меньше места остается для квалифицированныз программеров со временем, и всё больше и больше освобождается для посредственностей.
Не совсем понятная тенденция - популяризация процесса прогрммирования. Всё равно ведь надо быть профессионалом, чтобы написать что-то стОящее.
 

Слопер
31 May 2002 2:11 PM
В самом деле какая-то дебилизация народа происходит. И всё в угоду одной, пусть и крупной, корпорации.
 

Qrot
31 May 2002 3:19 PM
2Слопер: не одной корпорации. любой конторе выгоднее нанять посредственность за посредственные деньги, если инструменты разработки позволяют создать при этои качественный продукт.
да и идеи, которые есть в шарпе, уже были воплощены в яве.
 

me - userinternet.com
31 May 2002 5:01 PM
>> Не совсем понятная тенденция - популяризация процесса прогрммирования

По-моему, так все абсолютно понятно: сколько можно платить охрененные бабки каким-то "профессионалам", если их софт глючит тоже? Программировать должна уметь каждая домохозяйка, так как это _существенно_ дешевле, чем услуги мнимых "профи".
 

Ron - rodionlenta.ru
31 May 2002 5:19 PM
2 Qrot: В большинстве случаев происходит на практике примерно так. Ищется заказчик, собирается RAD-команда, берут они в каждую руку по мыши. Тяп-ляп, какую-то херню за месячишко нарисовали. Куча говна, баг на баге. Заказчик плюётся, матерится, но работать как-то надо. Люди обещают доделать. Пока доделывают одно - всплывает другое, пока доделывают другое - обнаруживается третье, пока третье переделают, оказывается, что какие-то требования поменялись и из-за этого надо уже переделывать первое. Так эта бодяга может тянуться несколько лет, в течении которых продукт на деле остаётся не продуктом, а недоделанной поделкой. А в итоге, пока всё это тянется, продукт становится заказчику по той или иной причине (изменение бизнес-процессов, обновления, появление новых технологий) не нужен и выкидывается. Все довольны. Заказчик худо-бедно всё это время работал. Разработчики худо-бедно всё это время получали деньги.

До нынешней работы поработал в двух разных местах программером - и там и там одно и то же. Скучно и уныло это. Не работа, а сплошной наебизнес. Хребты ломать надо за такое.

PS. Сейчас работаю админом, всем доволен, и обратно в здешний девелопмент возвращаться нет никакого желания :((
 

Qrot
31 May 2002 10:56 PM
2Ron: я в курсе, как это происходит. причем не обязательно команда набирается заново - есть куча контор, которые с этого живут.. типа с поддержки - мечта GPL-щиков, не к ночи будь помянуты.

2me: каждая домохозяйка должна уметь готовить вкусную и здоровую пищу, а не программы писать.
что значит "каким-то "проессионалам" и "мнимых "профи"? профессионализм бывает и настоящий.. сюрприз? :) я как-то не понял сарказм в твоем посте.
 

Ron - rodionlenta.ru
1 Jun 2002 2:44 PM
2 Qrot: Загибается отрасль... :((
Остаётся только ждать, когда домохозяйки на шарпе и VB начнут софт для ядерных реакторов писать, и наступит всеобщий pizdez...
 

Слопер
1 Jun 2002 5:26 PM
Наверное, просто заказчик не всегда может разобраться в тех людях и их компетенции, которых он нанимает. Вот и процветает серость и безграмотность, и появляются "новые" технологии, которые, вобщем-то нужны больше всего фирмам, которые их создают, и программистам-недоучкам (которых гораздо больше, чем настоящих профессионалов).
Еще, конечно, очень сильно оказывает влияние монопольное положение фирм-разработчиков технологий. А с другой стороны, без крупных фирм было бы меньше стандартов.
Короче, нехватает вмешательства какой-то третьей стороны, достаточно мощной, чтобы ограничивать монополии, и достаточно компетентной, чтобы заниматься стандартизацией компьютерных разработок.
 

Слопер
1 Jun 2002 5:27 PM
Вдобавок наблюдается дефицит квалифицированного персонала. И это, наверное, пожалуй главный фактор, который способствует "популяризации" программирования.
 

RIK
2 Jun 2002 11:29 AM
В средние века считалось, что не любого человека можно обучить грамоте. А потом выяснилось, что читать и писать можно и нужно учиться всем, а не только потенциальным великим писателям. С умением программировать та же ситуация ИМХО - то, что программировать будут домохозяйки окажет примерно такое же влияние на состояние отрасли, как всеобщая грамотность на состояние литературы (т.е. скорее положительное, чем отрицательное).
Впрочем, повторюсь, C# - это IMHO _не язык для домохозяек_. И основные достоинства этого языка, возможно, проявятся в _больших_ проектах.
 

me - userinternet.com
2 Jun 2002 9:31 PM
>> каждая домохозяйка должна уметь готовить вкусную и здоровую пищу, а не программы писать.
Qrot, ты мыслишь как девелопер в самом расцвете сил: я, типа, самый умный, а остальные быдло и пускай кормят меня теперь. Домохозяйка не просто должна уметь готовить вкусную и здоровую пищу, но еще ей следует делать это по возможности очень быстро, чтобы на уборку время осталось:)) Для этого, несомненно, нужна автоматизация трудового процесса. Вряд ли си-шарп, ВБ или, не дай бог, с++ займут нишу в подобной области из-за своей совершенно дикой сложности (я сравниваю с пылесосом, например, или с кофеваркой, где пара кнопок - и все). Но, по крайней мере, они двигают прогресс именно в этом направлении.

>> я как-то не понял сарказм в твоем посте
Очень не люблю заявлений типа "профессионалы могут все". Попробуй-ка объясни заказчику, который сначала выложил деньги за _очень_ квалифицированных работников, что всякая программа глючит и по-другому не бывает...

>> Загибается отрасль...
Слющай, не гони волну, да? :))) Отрасль движется вперед громадными шагами. Догоняй лучше, а не стони.

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

А вот с RIK'ом я абсолютно согласен: многие из вас, уважаемые профессионалы, никогда бы не увидели компутер, если бы не его всеобщая _популяризация_.
 

eXOR - billgmicrosoft.com
3 Jun 2002 9:46 AM
2 me:
Как ни неприятно это осознавать. Я с тобой согласен :-(.
 

Ron - rodionlenta.ru
3 Jun 2002 10:20 AM
2 me: Хорош прогресс... А оперировать кто должен, опытный хирург? Или нужно изобрести такой рулезный, прогрессивный скальпель, которым это сантехник сможет и станет делать?
 

Ron - rodionlenta.ru
3 Jun 2002 10:25 AM
Я не против домохозяек. Просто, программирование программированию рознь. У младшего в книжке прямо в первой главе объясняется, какая разница между "программой", "программным продуктом", "программной системой" и "системным программным продуктом". Пусть домохозяйки пишут _программы_, для управления той же своей кофеваркой, но всё остальное (с приставками "системный" и "продукт") должно создаваться людьми на этом специализирующимися.
 

miroh
3 Jun 2002 11:15 AM
Странно господа....
Я что то не вижу особой возможности чайникам занять место профи. Если раньше серьезной задачей было построение оконной системы, с элементами управления, то теперь это просто,зато появились современные задачки. Например создание распределенной системы обработки данных со всякими транзакциями, распределением нагрузки, интеграции серверов писюков и мобильников. Такое на дельфях не слабать за недельку - это работа для профессионалов.
 

Qrot
3 Jun 2002 12:15 PM
2me: не знаю, как насчет девелопера в расцвете сил и быдла, но, ИМХО, за мою работу мне должны платить деньги и чем больше - тем лучше. я не альтруист, знаете ли, и пекусь о своем благе исключительно. так вот, пока что я вижу, что шарп мой труд удешевляет - с одной стороны понятно, что это прогресс и от этого никуда не деться, но с другой - кушать тоже хочется.

и ты разделяй профессиональное прграммирование (это когда "системный продукт" на выходе) и тыканье в кнопки на кофеварке (кстати, кофе из кофеварок - говно полное, уж лучше ручками в турке). ИМХО, мы тут говорим о не о тыканьи в кнопки на кухне..

а сарказм я так и не понял - при чем здесь профессионализм?
 

Qrot
3 Jun 2002 12:20 PM
2miroh: согласен полностью. только пока что видно следующее - наберут студентов писать на новом супер-пупер языке и вперед! сроки - ну не неделька, но два-три месяца. раньше таким языком дельфы были и VB, потом- ява, теперь - шарп. кто следующий?
 

Qrot
3 Jun 2002 12:23 PM
2me: и, кстати, я вообще против автоматики для приготовления еды на кухне - не вкусно :)
 

PTO - kruchkovkgb.ru
3 Jun 2002 12:58 PM
2Qrot: это у тебя не было настоящей экспрессо-машин, которая кофе делает хороший... ни в какой турке ты не сделаешь такого вкусного экспрессо, как в топовой модели САЕКО... давленьеце там в 15 бар идет, отсюда и вкус и аромат и тонизирующий эффект...
 

me - userinternet.com
3 Jun 2002 1:02 PM
>> пока что я вижу, что шарп мой труд удешевляет
miroh правильную мысль высказал, что задачи не заканчиваются написанием гуя. Есть еще много всего нерешенного.

>> я вообще против автоматики для приготовления еды на кухне - не вкусно
Не пришло еще время хорошей автоматики. У тебя есть шанс приблизить его:))

>> Или нужно изобрести такой рулезный, прогрессивный скальпель, которым это сантехник сможет и станет делать?
ДА!!! Прогресс идет в сторону того, чтобы научить всех делать всё. Потому что это дешевле для конечного пользователя. Если у тебя засорится канализация, то ты, конечно же, вместо пачканья своей одежды и "рук", зовешь опытного сантехника, который запросит кучу бабла за 20 минут работы. Но стоит тебе только научиться чистить унитазы самостоятельно без фатальных последствий :)) - ты будешь все делать сам. И это правильно!

>> сарказм я так и не понял - при чем здесь профессионализм?
Профессионалы от любителей (читай: от программистов-недоучек) отличаются только тем, что работают за деньги и никак иначе. А в этом топике термины "профессионал" и "профессиональное программирование" употребляются в несколько ином контексте, чем и вызывают мое недовольство. Вот и весь сарказм.
 

me - userinternet.com
3 Jun 2002 1:05 PM
Этой статьи нет в списке "Все темы" :((
Жаль. На рекорд идем, однако:))
 

eXOR - billgmicrosoft.com
3 Jun 2002 1:15 PM
2 me:
>Но стоит тебе только научиться чистить унитазы самостоятельно без
>фатальных последствий :)) - ты будешь все делать сам. И это
>правильно!
Возвращаемся к натуральному хозяйству? Вроде бы стоимость специалиста в одной области всегда была ниже стоимости специалиста широкого профиля - это а, а качество было выше - это б. По этому и появилось разделенние труда и имхо оно и есть рулез.
Если физик - теоретик начнет тратить свое драгоценное время на то чтобы:
1) почистить унитаз
2) починить кофеварку
3) приготовить обед
4) написать программу
как ты думаешь какой будет отдача от такого ученого? Как ты думаешь почему в штатах образование специализированное? Как ты думаешь почему европа и мы движемся к тому же?
 

eXOR - billgmicrosoft.com
3 Jun 2002 1:15 PM
в общем история - она рулез... и очень не любит когда ее забывают.
 

Valeriy - valeriyy2kmail.ru
3 Jun 2002 1:28 PM
2 me: все не должны уметь делать все, если у меня сломается автомобиль, я позову опытного механика, который сможет быстро и квалифицированно починить его. Если этим я буду заниматься сам -- расход времени а соответственно и денег будет намного больше. А аппендицит тоже самому себе нужно вырезать? И костюм себе тоже шить самостоятельно?
Мое мнение -- разработкой серьезного ПО должны заниматься квалифицированные, высокооплачиваемые программисты; разработкой формочек к Access, прототипов систем, и приложений не критичных ко времени выполнения, быстродействию, затратам ресурсов, должны заниматься программисты средней квалификации; программированием кофеварок и видеомагнитофонов должны заниматься домохозяйки.

2 Qrot:"шарп мой труд удешевляет " да нет, он позволяет увеличить производительность труда программиста, а значит делает его, и как следствие всю команду, более конкурентноспособной, а это не обязательно означает снижение доходов. Полностью согласен с miroh, задач для квалифицированных программистов более чем достаточно.
 

Ron - rodionlenta.ru
3 Jun 2002 2:07 PM
ИМХО. В огромном количестве фуфлового, падучего, тормозного, вечно недоделанного, недокументированного, неоттестированного, не имеющего нормально собранного дистрибутива, работающего только в присутствии программера, сопровождаемого через жопу и т.д. и т.п., можно продолжить, софта (в основном - отечественного), большая доля вины RAD средств. А в основном - угадайте какого.
 

miroh
3 Jun 2002 2:16 PM
2Valriy
Программированием кофеварок и видеомагнитофонов скоро будут заниматься профессиональные Java программеры. Уже сейчас они программируют мобильники. Я посмотрел на MIDP API - Очень даже приличные возможност. Есть где развернуться и изгальнуться
 

Ron - rodionlenta.ru
3 Jun 2002 2:21 PM
Вспомнил сейчас историю. Было бы смешно, если бы не было так грустно. Делается на заказ прожект. Делает команда делфистов, этакие шустрые, с огнём в глазах, вагоном энтузиазма, "рейпид-разработчики", берущиеся супер-систему за две недели слепить.
Так вот. Вроде сделали, приезжают они к заказчику, копируют со своих дисков. Тут выясняется, что где-то в проге в коннекшион-стринге захардкодили имя сервера. Зовут админа. Так и так, типа, давай ваш сервер переименуем, а то работать не будет. Админ, ессно, рассказывает им чью маму навестить. Тогда, недолго думая, один чувачок сгоняет бабусю с ближайшего компа, инсталлирует на него Дельфи с диска, правит в исходниках имя сервера, пересобирает прогу и ставит её.
 

Qrot
3 Jun 2002 2:38 PM
2Valery & me: ОК. повышает производительность -> увеличивается кол-во труда за единицы времени + оплата по времени -> снижение оплаты в сумме. и это не зависимо от того что делать - логику или гуй. причем, такая деталь - логику по трудозатратам одинаково писать на плюсах что на шарпе.

2me: поставь период месяц и все увидишь.
ладно, хрен с ними, с "профи" :)

2РТО: у меня на этот счет есть своя теория - если готовишь еду не автоматически, а ручками, то ты в нее душу вкладываешь.. автомат может и в нужных пропорциях смешает, но будет уже не то. так что, я приветствую автоматику на кухне только в виде посудомоечных машин :)
а насчет чей кофе будет лучше - это еще как посмотреть :) я не большой спец, но иногда такой получается, что сам удивляюсь.
 

Qrot
3 Jun 2002 2:58 PM
2miroh: да они все о каком то другом программировани говорят.. типа на кнопки потыкать на кухне.
а на яве для девайсов писать было бы неплохо.. куча проблем бы ушла сразу. сейчас, насколько я в курсе, большинство пишет на сях, причем доисторических времен - у нас вон компилер от 85-го года, библиотек никаких нет, все сам пишешь form scratch :(
 

me - userinternet.com
3 Jun 2002 3:10 PM
eXOR, ты не понял:))
Дело в том, что я, например, представляю как чистить канализацию (видел, но не участвовал), но все равно обращусь к спецам в этом деле:)). То же самое касается и одежды, и аппендицита, и автомобиля. Но, говоря "все должны уметь делать всё", я вовсе не подразумеваю, чтобы они (все) делали это (всё) руками: будут автоматические средства. И у этих автоматических средств всегда будут противники на подобие Qrot'а, так как они _действительно_ отбирают хлеб насущный. Вот только цель их не в том, чтобы лишить кого-то работы, а том, чтобы облегчить жизнь потребителю. И такое положение вещей - вовсе не натуральное хозяйство: каждый делает (в смысле, _сам_, руками) только то, что умеет, а все остальное делает автоматика, а _не_ специалисты.
 

Valeriy - valeriyy2kmail.ru
3 Jun 2002 3:24 PM
2 Qrot: Странная арифметика, сразу возникает желание максимально затянуть разработку, и как следствие, увеличить сумму заработка. Обычно заказчик определяет рамки проекта, и выделяет определенную сумму денег. Используя средства позволяющие повысить производительность труда программистов, можно этот срок сократить, соответственно увеличить доход программиста за определенный промежуток времени. К тому же можно еще и за срочность выполнения получить дополнительные деньги, но это уже как повезет.

2 Ron: По поводу поучительной и грустной истории. Быстрее всего проблема не в Делфи, а в неверном проектировании самой системы, и построении процесса разработки, такие проблемы должны проявляться на стадии альфа-версии, а не при передаче заказчику.

RAD средства могут быть очень полезны, например при разработке одного/нескольких прототипов системы, также можно не дожидаясь разработки основных компонентов, разрабатывать интерфейс пользователя и usability.
 

Ron - rodionlenta.ru
3 Jun 2002 3:35 PM
2 Valeriy: Понимаешь ли, я отлично сознаю, что проблема не в Делфи. Я постингов 100 :-) назад, кажись, писал, что проблема, просто-напросто, втом, что RAD-средства прямо-таки толкают программера на то чтобы сесть писать код нифига заранее не продумав.
 

Valeriy - valeriyy2kmail.ru
3 Jun 2002 3:53 PM
2 Ron: Полностью согласен, но это же не значит, что RAD-средства нужно запретить. Еще раз, это недостаток культуры разработки. Если работает команда, значит должен быть человек/группа людей занимающиеся проектированием, они и выбирают язык разработки, средства разработки на определенном участке работы. Они и ставят однозначные требования к кодировщикам, с последующей проверкой всего/части кода. Должны быть выработанны пронципы разработки общие для всей команды, ну и т.д. т.п.. Иначе вероятность получения положительного результата ничтожная.
 

Qrot
3 Jun 2002 5:25 PM
2Valery: ну а ты что, не в курсе, что заказчики по большей части долбанутые люди которым нужно вот прям здесь и сейчас? или ты никогда не замечал, что использование RAD средств толкает менеджеров на занижение сроков? в результате, вместо 12 месяцев будет 4 - уже только потому, что C# (Delphi, Java, etc) типа круто повышает производительность.. а что у тебя студенты на нем пишут - кого это волнует? отсюда - оплата за 4 месяца, работа по субботам и с 9 до 7 по будням официально. на заре свой трудовой деятельности (так сказать) я имел счастье работать с подобными "манагерами"... они впрочем и по сей день (уже лет 5-6) так работают - и зарплата у пргораммеров $400 (это максимум). это за 10 часовой рабочий день и сверхурочные по субботам.. и за то что эти проги еще и ТЗ сами пишут.. они же "не просто программисты", бл$дь! вот такой вот рулез эти ваши RADы - в случае с плюсами хоть понятно, что совсем больные на голову люди в манагеры не пройдут, а тут вообще никаких препятствий нет.
 

me - userinternet.com
3 Jun 2002 9:21 PM
Qrot, я почти в такой конторе работал:)) Платили там, правда, больше, но должность менеджера была аккуратно размазана по всему персоналу и многие работали по выходным. Да, и кстати... Из RAD средств использовался JBuilder4, если его так можно назвать: от блокнота отличается возможностью подсвечивать буковки (утрирую, конечно)... И кого винить? Borland/Inprise?
 

Qrot
3 Jun 2002 9:55 PM
me, C++ Builder :) винить конечно же не Borland. дело в культуре менеджмента, ИМХО (не уверен, что это правильное название, но пока и такое сойдет, смысл отражает). насколько я вижу по своему опыту и по рассказам знакомых - в IT (у нас по крайней мере) этой самой культуры практически нет. манагер может сказать, что его люди сделают проект с нуля практически за любой, пусть даже самый короткий срок, лишь бы заполучить заказ или не потерять свое место. и RAD ему в этом помогает и очень сильно, чего не скажешь про плюсы или си. в результате, за слова манагера отвечают его подчиненные - своими деньгами, карьерой, здоровьем, потому что независимо от того, используется RAD-средство или чистый ЯП, все равно остается логика, которую на RAD просто так не нарисуешь.
я не знаю, кому то мои слова могут показаться утрированием, передергиванием, выдумкой - но это реальный опыт. для меня прошлый, к счастью. но все знакомые, кто работает с Delphi или c Builder - говорят то же самое, если не хуже (про МВ я тут писал уже как то).
 

Valeriy - valeriyy2kmail.ru
4 Jun 2002 9:27 AM
2 Qrot: "заказчики по большей части долбанутые люди которым нужно вот прям здесь и сейчас" -- заказчики по большей части толковые люди, которые умеют зарабатытать деньги, и умеют их тратить, а "долбанутые люди " -- это те кто обещает им "здесь и сейчас".
"использование RAD средств толкает менеджеров на занижение сроков" да пусть толкает, в конечном итоге у нас больше заказов будет. Сейчас мы как раз заканчиваем заказ с подобной историей.
"... студенты на нем пишут ...работа по субботам и с 9 до 7 по будням официально... вот такой вот рулез эти ваши RADы " действительно RADы виноваты.
"дело в культуре менеджмента" вот с этим полностью согласен.
 

miroh
4 Jun 2002 10:00 AM
Блин ниче не понимаю... Как RAD может жизнь облегчить кардинально? Ну уй состряпать, ну к бд присосаться,а основная работа все равно руками.Я правда в делфях не работал, но по моему опыту этим RAD ом пользуешся максимум первый день когда заготовку стряпаешь,а потом какой уж там RAD?
 

Qrot
4 Jun 2002 10:32 AM
2Valery: мне положить с высокой колокольни, умеют заказчики тратить деньги или нет. применительно к нашей теме - заказчик хочет максимально занизить срок, остальное не существенно. а дальше, как я смотрю, ты со мной согласился :)

2miroh: да я вот тоже не понимаю... это, ИМХО, вопрос к манагерам - как это так у них получается?
 

Ron - rodionlenta.ru
4 Jun 2002 10:50 AM
Даже насчёт того, что в RAD гуй состряпать и к БД законнектиться, можно поспорить. Как в тех же дельфях слепить форму, чтобы она так же легко поддавалась локализации, как в случае использования ресурса диалога? Как сделать в дельфях коннекшион с БД, чтобы можно было в рантайме настроить его параметры? Кажись, всё это можно сделать, только не прописывая пропертя мышкой в RAD, а делая всё это руками в коде. Вот и выходит, что RAD ускоряет только изготовление поделки какой-то, а если писать, как оно должно быть написано для продукта, то объёмы кодирования те же самые.
 

miroh
4 Jun 2002 11:40 AM
вот вот...
RAD только для того и нужен, чтоб проделать в самом начале муторную глупую работку по созданию заготовки, а дальше сам... В общем опасения о упрощении программирования беспочвенны...
 

Qrot
4 Jun 2002 11:55 AM
ИМХО, вся фишка именно в том, что эту глупую морду можно быстро слабать и заказчику под нос сунуть - типа вот, уже сделали.. для многих манагеров гуйня + минимальная работа с базой является по сути готовым проектом уже, а остальное типа само приложется.

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

Shadow
4 Jun 2002 12:53 PM
Мать-перемать... Язык для домохозяек? Он ДОЛЖЕН быть ЕЩЁ тупее чем старый-добрый BASIC!!!
Вы понимаете, о чём я? ПРАВИЛЬНО!!!! PHP- ЯЗЫК ДЛЯ ДЕБИЛОВ!!! Самый дебильный язык, потому его так все любят. И хватить бредить домохозяйками. Правильно сказано - c# для больших проектов задумывался, а на самом деле - в пику яве. А на самом деле - c++ ничуть не сложнее для решения тех задач, которые решают шарпом.
 

Shadow
4 Jun 2002 12:56 PM
По поводу канализации... Тросики и вантузы в магазинах не для сантехников продают... А забитый сток в 3 утра - это явно не для специалиста, видящего десятый сон.
 

me - userinternet.com
4 Jun 2002 2:31 PM
>> Он ДОЛЖЕН быть ЕЩЁ тупее чем старый-добрый BASIC!!!
Несомненно! Что-то типа: "засорился - почистить". Не сложнее:))

>> Тросики и вантузы в магазинах не для сантехников продают
Признаюсь, что пример с канализацией сильно преувеличен:))
 

eXOR - billgmicrosoft.com
4 Jun 2002 4:17 PM
2 me:
Типа сделать всех - всех программистами :-)? Может быть для начала хотя бы научить их этих всех понимать базовые понятия... типа файл там или программа...
 

eXOR - billgmicrosoft.com
4 Jun 2002 4:19 PM
2 Shadow:
> ПРАВИЛЬНО!!!! PHP- ЯЗЫК ДЛЯ ДЕБИЛОВ!!!
Приятно увидеть постинг умного человека. К тому же ставящего по четыре воскрецательных знака. Пологаю вы имеете веские основания называть всех PHP программистов (хотя скорее название некорректное) дебилами.
 

eXOR - billgmicrosoft.com
4 Jun 2002 4:20 PM
2 me:
> "засорился - почистить". Не сложнее:))
Так а зачем такие типовые вещи задавать? Может быть не нужен нах язык для таких операций?
 

Слопер
4 Jun 2002 6:44 PM
Если говорить о том, что программирование - это искусство (например, как у Кнутта), тогда никакие новейшие средства разработки и опять же новейшие языки программирования не заменят профессионала.
Вопрос только в том, что количество программ, в которых нужно присутствие мастеров, на мой взгляд (чисто субъективное мнение), гораздо меньше количества программ, в которых такое присутствие не обязательно (хоть и желательно).
Новые языки, средства быстрой разработки приложений призваны в большей мере удовлетворить недостаток профессионалов, нежели ускорить разработку проектов. У профессионалов, по-моему, в их багаже и так достаточно готовых решений, позволяющих значительно ускорять разработку. Они же (профессионалы) не вчера родились.

Речь идет также о том, чтобы максимально возможное количество технологических приемов программирования донести до программистов средней и низшей квалификации. Сделать их достоянием широкой публики.

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

Слопер
4 Jun 2002 6:47 PM
Короче, чтобы отрасль не "загнулась", как говорит Ron, надо нести больше света, то бишь знаний, в темные народные массы.
 

RIK
4 Jun 2002 8:02 PM
2 Слопер
>средства быстрой разработки приложений призваны в большей мере удовлетворить недостаток профессионалов, нежели ускорить разработку проектов.

Совершенно согласен (под словом "профессионал" здесь, видимо, надо понимать "хороший программист"). Я приводил пример с всеобщей грамотностью - она не отбирает работу у писателей (хотя казалось бы - писать-то теперь все умеют). Равно как появление авторучек взамен гусиным перьям.

2 All
Возвращаясь к теме сборщика мусора. Вероятно, что сборщик мусора будет включен в следующий стандарт C++.
 

Ron - rodionlenta.ru
4 Jun 2002 10:05 PM
2 RIK: > "Вероятно, что сборщик мусора будет включен в следующий стандарт C++"

Очень сомнительно, хотя ожидать всего можно. Это идёт в противовес всей идеологии С и С++. Со времён Кёрнигана с Ричи "фирменной" фичей Сей являлось отсутствие каких-либо встроенных в синтаксис языка фишек, которые по реализации сложнее чем пара машинных команд (мальца утрирую, плз, не придирайтесь). В С (да и в С++ тоже) нет встроенных в язык ни операций ввода/вывода, ни конструкций управления памятью - всё делается через библиотечные ф-ии. "Операторы" new и delete, введённые Страуструпом в плюсы являются такими же библиотечными функциями, как и malloc/free в Сях.

Сборщик мусора, имхо, пусть вводят, но только, разумеется, не в стандарт C++, а, к примеру, в стандарт STL. Буду только двумя руками за.
 

me - userinternet.com
4 Jun 2002 11:01 PM
>> Полный оффтопик
Я плакалъ:))

>> Типа сделать всех - всех программистами
Не совсем: научить всех-всех программировать (хоть на каком-нибудь уровне) - вот высшая цель. RIK правильно отметил, что писать все умеют, но работу такое положение вещей ни у кого не отнимает. Так пусть все будут уметь автоматизировать свою деятельность. Как бы это ни было утопично:))

>> Может быть не нужен нах язык для таких операций?
Нужен. Назовем его русским:)) Главное, чтобы с его помощью можно было описать некоторую последовательность действий. Причем _заранее_:))
 

Shadow
5 Jun 2002 12:44 AM
2 eXOR:
У Вас нелогичный вывод. Как раз php разработчики - умные люди, бо не ломают себе голову всякими сложностями, когда можно сделать проще.
Просто человек6 которому нужен контент динамический, и который из программирования помнит что-то про паскаль, видит php, у него лицо только что просветлившегося. И самый ленивый или тупой индивидуум справится с php!
 

Shadow
5 Jun 2002 12:47 AM
Да, чего нельзя сказать про c#...
 

Valeriy - valeriyy2kmail.ru
5 Jun 2002 10:12 AM
2 Слоппер: "Новые языки, средства быстрой разработки приложений призваны в большей мере удовлетворить недостаток профессионалов, нежели ускорить разработку проектов"

Неужели удобная, интегрированная, визуальная среда разработки не ускоряет разработку проектов профессионалами? А удобное и надежное хранилище исходников с поддержкой истории внесения изменений? Практика показывает обратное.

2 RIK: > "Вероятно, что сборщик мусора будет включен в следующий стандарт C++" Врятли, Страуструп против внесения сборщика мусора в стандарт С++, аргументируя тем, что есть много библиотек реализующих сборку мусора в С++, можно с успехом их использовать. http://www.research.att.com/~bs/bs_faq.html#garbage-collecti on

2 me:"научить всех-всех программировать " я, если честно, очень сомневаюсь, что "все-все" захотят программировать, что-то сложнее стиральной машинки, посредством 3-4 клавиш конечно, а не Java. Так же как я не захочу сам строить дом, мастерить мебель, и шить одежду.
 

Qrot
5 Jun 2002 10:29 AM
2Shadow: можно, только паскакал на плюсы замени :)

2Ron: та не, скорее всего речь идет о следующей версии stl (которая, кстати входит в стандарт плюсов, а не отдельно идет). туда же вроде бы планировали добавить треды и сокеты - жду н дождусь.

2RIK: ну да все умеют писать, но не все становятся писателями. но плохие писатели откуда беруться? или певцы безголосые? они хлебушек то под себя гребут...
 

RIK
5 Jun 2002 11:32 AM
2 Qrot
Разумеется, всеобщая грамотность ведет к увеличению количества графоманов. Что, впрочем, не слишком дорогая плата за прогресс и не является поводом для отмены обучения детей грамоте.

2 All
Страуструп как раз за, а тормозит комитет по стандартизации.
 

me - userinternet.com
5 Jun 2002 12:06 PM
>> туда же вроде бы планировали добавить треды и сокеты
Ну наконец-то:))
 

Qrot
5 Jun 2002 12:15 PM
2RIK: а с чего ты взял, что я против обучения детей грамоте? или, если перевести, против обучения юзеров основам работы с бытовой техникой и компьютерами? мне не нравится существование огромной массы малоквалифицированных программистов, ничего не умеющих и не знающих, кроме как тыканья мышой в панель инструментов. вобзращаясь обратно, это все равно что каждого ребенка обучать генерации книжонок в мягкой обложке - шаблон уже есть, имена героев задал, кой какие свойства у них поменял и вперед! продавай на лотках это чтиво..
 

Valeriy - valeriyy2kmail.ru
5 Jun 2002 12:20 PM
2 RIK: "If you want automatic garbage collection, there are good commercial and public-domain garbage collectors for C++. For applications where garbage collection is suitable, C++ is an excellent garbage collected language with a performance that compares favorably with other garbage collected languages. ... Also, C++ supports programming techniques that allows memory management to be safe and implicit without a garbage collector.
" (c) Bjarne Stroustrup http://www.research.att.com/~bs/bs_faq.html

К тому же Страуструп состоит председателем рабочей группы по расширению языка в комитете по стандартизации ANSI и ISO.
 

RIK
5 Jun 2002 1:17 PM
2 Qrot
Ну мне, собственно, тоже не нравится существование огромной массы малоквалифицированных программистов. Однако хороших программистов, как и хороших писателей, немного и заметного увеличения их количества, похоже, не предвидится.

2 Valeriy
Насколько я знаю, сейчас мнение Страуструпа по поводу сборщика мусора несколько отличается от изложенного в этом документе. Что же касается его председательства в комитете - это мало что значит. Там демократия - каждый член комитета имеет ровно один голос.
 

eXOR - billgmicrosoft.com
5 Jun 2002 1:38 PM
2 me:
Вот объясни, а нахур тогда будет нужон C#? Если в STL будут gc/sockets/threads?

2 Shadow:
> Да, чего нельзя сказать про c#...
почему?
 

Qrot
5 Jun 2002 3:00 PM
2eXOR: шарп помимо всего прочего еще и часть .нет фреймворка с кучей специфических фенечек - он и нужен собственно, что бы под .нет писать.
 

Qrot
5 Jun 2002 4:15 PM
м-да.. приходится признать, что на плюсах отдельные.. гм.. тоже встречаются - сейчас приходится разбирать сорсы по одному из проектов.. сижу, матерюсь, разбираю.. человек не имеет ни малейшего понятия ни о чем, кроме собственно среды VS и front-end'а MFC.. про ООП я уж вообще молчу. типичный представитель, короче. но что радует - исходя из такой работы, далеко ему пройти не удастся и уж манагером он не станет, а если и станет, то будет смотреть в рот своему ведущему спецу и почтительно внимать каждому слову - иначе медным тазом такого манагера накроет и очень быстро.
 

Ron - rodionlenta.ru
5 Jun 2002 4:41 PM
"Also, C++ supports programming techniques that allows memory management to be safe and implicit without a garbage collector."
Вау !!! Да он прямо меня процитировал !!! :-)))
 

eXOR - billgmicrosoft.com
6 Jun 2002 7:43 AM
2 Qrot:
Вот... это кстати к теме о чиста канкретных пацанах - юниксойдах :-). Как я уже говорил... чиста канкретные пацаны - кроссплатформенны.

2 Ron:
А может ты и он - это один и тот же человек? :-)
 

eXOR - billgmicrosoft.com
6 Jun 2002 7:44 AM
2 Qrot:
Про .NET...
дыкть можно и на managed C писать под .NET, можно и под unmanaged тоже... так что вопрос так и остается открытым.
 

Qrot
6 Jun 2002 10:14 AM
2eXOR: можно, но не удобно.. думается, это будет таже фигня как и с плюсами и COM - работать с дисп-интерфейсами можно но не удобно, на VB или скриптах значительно удобнее.

с кроссплатформенностью чиста канкретных пацанов абсолютно согласен :) пора уже на самом деле называть их просто красноглазыми, с легкой руки Irsi :)
 

eXOR - billgmicrosoft.com
6 Jun 2002 12:36 PM
2 Qrot:
Не надо красноглазыми... у меня глаза с перепою или с завершенния проекта краснеют, у тебя думаю тоже...
 

 

← апрель 2002 1  3  6  7  8  10  11  12  13 июнь 2002 →
Реклама!
 

 

Место для Вашей рекламы!