Re[14]: why off?
От: c-smile Канада http://terrainformatica.com
Дата: 11.11.05 00:46
Оценка: 73 (9) +1 :))) :))) :))) :))) :))) :))) :))) :))) :)))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А они, как правило, аргументируют примерно так:


Геннадий мое почтение, получил масс удовольствия

Только ты не дописал...

Действующие лица:

Евангелист, он же коммивояжер, исполнитель скажем Дон Коробочка.
Глашатай, ну сами знаете кто.
Он, Геннадий например.
Угрюмый, простой инженер, он же девелопер.

Действо №1:

Угрюмый: ...так это я написал... как бы его назвать? Пусть будет CORBA...
Евангелист (шепотом, смотря из-за плеча) "ух ты!"


Ария Евангелиста:
(место действия VSLive New York 2001):
Так, пацаны, бросайте все, вот вам .COM.
Вот смотирте жмем кнопку тут и все — оно само жужжит.
И самое главное! У нас уже все на нем пишут!

Глашатай (восторженно): Ура! (уходит окрыленный в массы...)

... тут идет рекурсивный вызов диалога который приведен внизу

Занавес.

Действо №2:

Угрюмый: ...так это я написал... как бы его назвать? Пусть будет Java Virtual Machine...
Евангелист (шепотом, смотря из-за плеча) "ух ты!"
.....

Ария Евангелиста (место действия VSLive SanFrancisco 2005):
Так, пацаны, бросайте .COM, с ним все оказолсь плохо.
Промашка вышла. Поэтому все переходим на .NET!
У нас уже все на нем написано, вот смотрите —
теперь даже кнопку жать не надо — оно само жужжит
а мусор который оно при этом делает сам шурша убирается. Клево, да?

Глашатай (восторженно): Гип-гип-ура! (уходит окрыленный в массы...)

...

Глашатай .Net: Мир поменялся! Всем переходить на .Net!
он: И я?!
Глашатай .Net: Да!
он: А почему?
Глашатай .Net: Так надо! У тебя проблемы с утечками памяти и <много всего>!
он: У мна? (ошарашенно оглядывается по сторонам) У мна их нет. Уж лет пять как.
Глашатай .Net: У меня есть проблемы! У моих коллег есть проблемы с галимым C++! Потому — все на .Net!
он: Хм... (скребя лысину) ну у всех есть проблемы конечно, а какие из них вы можете решить?
Глашатай .Net: ВСЕ!
он: (показывая пальцем в распечатку, с надеждой) а вот эту?
Глашатай .Net: ЛЕГКО! (отрывает кусок распечатки и выбрасывает) Это теперь МУСОР, пацан, забудь!
он: Постойте но как же он... того...
Глашатай .Net: От пристал... у нея там думатель унутре. Понял?! И вообще речь не о том!
Главное что порог вхождения низкий...
он: Хм... а я уже здесь как бы. Мне выйти и зайти?
Глашатай .Net: От ты, пацан, нудный... Ты, пацан, лучше уйди ваапще.
Я в трех фирмах секретных работал... Бааальших-пре-больших,
в три раза бОльших индийских бодишопов и нигде таких нудных не видел...

(Тут продуктивня беседа прерывается криком)
Крик Евангелиста: Девлоперс, девлоперс, девлоперс!
Глашатай .Net: Слышу, слышу... (переходит в следующую комнату)
Угрюмый: (напевает под нос) девлоперс, девелоперс, да мы девелоперс...
так это я написал... как бы его назвать? Ну скажем Web2...

Евангелист (шепотом, смотря из-за плеча) "ух ты!"

....

Ария Евангелиста (место действия недалекое будущее):
Так, пацаны, писали мы писали ту Висту.... корче так, все на .WEB !

---------
Мужики, без личных обид пожалуйста.
С++ culture
От: Ligen Украина http://zone-of-ambiguity.blogspot.com/
Дата: 19.10.05 13:00
Оценка: 91 (12) +5 :))) :))) :)
"Слава, слава дракону!"
Навеяно агрессивными постами дотНетовцев, похвально стремящихся к мировому господству (ветка писал на с++
Автор: VladD2
Дата: 18.10.05
).
Дескрипшн: No holy wars. Зачем?

Можно наблюдать интереснейшую тенденцию:
1. кол-во проектов на С++ возрастает.
И флудилось об этом уже неоднократно, про ниши там разные и т.д.
Но факт в том, что поддерживаются и развиваются старые проекты, создаются новые etc..
2. а что насчет кол-ва С++ программеров?
Что дают дотнетовцам лозунги вида:
"память, процессор, видуха — не ресурс",
"ребята, да тут нет граблей!",
"создаем проги пачками!",...
"тут тепло и любят поэтов!"?
А то, что многие существа биологического вида lamerus comatosus и просто многие молодые ребята толпами валят в .Нэт. Более того, им часто это советуют гуру (не кидаюсь ссылками, ибо некультурно).
Есс-но в мире .Нэт как и везде много профессионалов (часто со славной историй С++-девелоперов, кстати), но
зачем изучать абстракцию на всех уровнях — если можно на одном, да повыше?
(хотя фраза "зачем мне это знать?" звучит всегда дико и убийственно, ИМХО).


Как следствие — спрос на С++ программистов возрастает неимоверно.
По С++ реально не хватает спецов. Часто девелопером может устроится человек с минимальным опытом — 5 лет назад такое казалось невозможным.
У меня лично за прошлую неделю было n обращений в аську(!) с предложениями сменить работу.
Опять таки, у С++ сообщества появляется оттенок элитизма, любезно упомянутый комрадами в ветке писал на с++
Автор: VladD2
Дата: 18.10.05


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

просто новые технологии с рынка не уходят — они его расширяют (-тоже, кажется, баян )
Viva el Junta Militar! Viva el Presidente!
Re: С++ culture
От: sch  
Дата: 19.10.05 14:59
Оценка: 11 (6) +13
А я вот честно говоря не понимаю причин, по которым спорят о преимуществах одних языков над другими языками, одних API над другими API, одних компиляторов над другими компиялторами. По моему скромному мнению, профессионал может работать с любыми языками, средставами, API, девкитами и прочим; все что нужно, для того, чтобы быть производительным -- компьютер, тишина и немного кофе.

Поймите меня правильно. Я программирую на C++, я люблю этот язык, знаю его норов, знаю тонкости его использования. Но если завтра мне будет нужно писать на C# -- я буду писать на C#, если будет нужно писать на Java -- буду писать на Java, а каким красивым и изящным может быть код на GW-BASIC... По моему скромному мнению, новый язык -- это здорово: можно взглянуть на кажущиеся неприступными истины.

Долой вражду на основе языков программирования.
Да здравствует языковый космополитизм.
Re[17]: why off?
От: Павел Кузнецов  
Дата: 17.11.05 04:08
Оценка: 93 (5) :))) :))) :))) :))) :)
VladD2,

> K>Тебя наверное сильно задел такой фанатик)

>
> Если бы это был один человек, то я бы и усом не повел. Но это какое-то групповое безумие. <...>

"По радио передают, что какой-то сумасшедший по встречке едет."
"Да тут их тысячи, тысячи!"
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[13]: why off?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 10.11.05 14:23
Оценка: 54 (6) +5 -1 :))) :))
Здравствуйте, mrozov, Вы писали:

M>Доказывать я что-то буду коллегии присяжных, да и то — только по совету моего адвоката. Я делюсь своим опытом и опытом моих коллег, которых я знаю лично.


Не хотите — не доказывайте, Ваше право. Но и не ждите серьёзного отношения к бездоказательным (сиречь — голосоловным) утверждениям.

M>Мои оппоненты делают в точности то же самое. Я почему-то не заметил, чтобы Вы потребовали доказательства репрезентативности их выборки.


А они, как правило, аргументируют примерно так:

Глашатай .Net: Мир поменялся! Всем переходить на .Net!
он: И я?!
Глашатай .Net: Да!
он: А почему?
Глашатай .Net: Так надо! У тебя проблемы с утечками памяти и <много всего>!
он: У мна? (ошарашенно оглядывается по сторонам) У мна их нет. Уж лет пять как.
Глашатай .Net: У меня есть проблемы! У моих коллег есть проблемы с галимым C++! Потому — все на .Net!
(долгая беседа с разбором конкретных случаев, когда особенности .Net и C# реально мешают делу, завершающаяся немой сценой и взаимными обидами)

Понимаете разницу между позицией одного и второго, нет? А кто здесь безапеляционен? Кто неправомерно обобщает?

M>Просто так уж сложилось, что за 10 лет практики я ни разу не столкнулся с задачей, которая требовала бы задействования тех преимуществ языка с++ над java/.net, которые действительно в реальности существуют, причем требовала бы не локально, не в двух-трех местах, а повсеместно.


Опять таки, трудно делать выводы относительно конкретной области Вашей практики.

M>Одно из приложений, которое сейчас находится у меня в разработке, написано на смеси c++ и с#. Просто для решения одной из подзадач с++ оказался удобнее. Но подзадача — сравнительно мелкая и легко изолируемая.

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

Стоп. Из этого следует, что выбор C++ обусловлен как раз преимуществами C++ в конкретном контексте. Пусть не как языка, но как системы программирования. Не так ли? А раз так, то какая разница, в чём именно они состоят?

M>.net, как раз, был бы гораздо удобнее.


Очень интереное противопоставление: "удобство vs. удовлетворение требований пользователей". Отметим.

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


Э... извините, не понял, о каких именно нюансах речь? Вы имеете ввиду, что Вам на порядок чаще, чем другим людям приходится использовать C++ вместо .Net?

M>Все это ни в малейшей степени не означает, что "жирафов не бывает". Разумеется, есть люди, которые исключительно такими задачами и занимаются. Просто мой личный (и не только мой) опыт заставляет меня крайне скептически относиться к предположениям, что таких задач — большинство.


Ещё раз — это только Ваш опыт.

M>Доказательств обратного, замечу, мне никто (включая Вас) не предоставил.


А я и не пытался ничего доказать. Утверждаете здесь Вы. Следовательно и доказывать свои утверждения должны Вы. Меня как раз и интересует обоснованость Вашей позиции.

M>Имею ли я право на свое мнение? Думаю, что да. Имеет ли мое мнение под собой веские основания? Думаю, что да. Прав ли я? Возможно, нет. Но пока мой подход себя оправдывал. Чего и Вам желаю.


Снимаю перед Вами шляпу, коллега. Из уст сторонника .Net такое слышишь не часто.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: С++ culture
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 10.11.05 00:31
Оценка: 51 (6) +3 :)))
Здравствуйте, mrozov, Вы писали:

ПК>>Это ваш опыт. Не пытайтесь его обобщать в категоричной форме на всех.

M>Нет, не мой. Это опыт трех компаний, в которых я работал (одна — очень крупная) и нескольких, делами которых я интересовался.
M>Это позволяет мне делать некоторые обобщающие выводы.

Следует, однако, отметить, что остаётся туманной репрезентативность опыта рассмотренных Вами компаний по отношению ко всей отрасли. Короче говоря, что одна компания, что три, всё равно это опыт конкретных компаний, который ну только очень условно может проецироваться на конкретные ситуации и людей. Я вот об этом:

E>В общем, мне кажется, что лозунги "Нужно писать на .Net, потому, что C++ глючный, т.к. я на нем пишу с ошибками" -- это такая же эмоция, как "C++ forever!". А выбор языка и платформы для конкретной задачи должен включать в себя анализ большого количества факторов. И очень жаль, что критерий "количество багов в C++ программах" для конкретной команды оказывается на одном из первых мест.

Да нет же, все не так. Нужно писать на .Net, потому, что C++ глючный, т.к. я, все мои знакомые программисты и подавляющее большинство других программистов, на нем пишут с ошибками. (Это предложение — вообще чистой воды иллюстрация к статье "как не надо строить доказательства". — ГВ.) А количество ошибок на .net заметно меньше, как и общая скорость разработки. И практика моей компании показывает, что стоимость решений на с++ оказывается неприемлимо высокой.


Здесь ещё нужно расспросить о:
— профиле компаний;
— сравниваемых продуктах;
— методике оценки;
— времени эксплуатации;
— количестве вовлечённых людей и их квалификации и т.п.

И только тогда можно будет в некоторой степени определиться с тем, как имено можно интерпретировать опыт Вашей компании в контексте какой-либо другой.

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

M>А про "на всех" пусть остается на Вашей совести.


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


ПК>>Зря вы не применяете этого же подхода к себе.


M>И опять не угадано ни одной буквы! То, что я в меньшинстве со своим пониманием опасности вызова CreateThread, я-то как раз прекрасно понимаю. А вот Вы в своей башне из слоновой кости бум web-программирования, похоже, благополучно проспали.


А какая связь между тем, что Вы "в меньшинстве" и "башней из слоновой кости"? А то я, что-то не понимаю.

M>Мир изменился.


"Я чувствую это в воде, я чувствую это в земле... О! Вот и в воздухе что-то..." (c)

Не сочтите за обиду, но Вам не смешно оперировать терминологией, которой оперируют дети в переходном возрасте и маркетологи?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: С++ culture
От: Kisloid Мухосранск  
Дата: 19.10.05 13:25
Оценка: :))) :))) :))) :))
Здравствуйте, Ligen, Вы писали:

L>Есть такой анекдот в виде тоста:

L>"- Пусть представителей сексуальных меньшинств станет больше!!
L> — ???!!
L> — нам достанется больше женщин! "
— главное чтобы мы никому не достались...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Re[14]: why off?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.05 00:58
Оценка: 51 (4) :))) :))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Не хотите — не доказывайте, Ваше право. Но и не ждите серьёзного отношения к бездоказательным (сиречь — голосоловным) утверждениям.


Твои утверждения не менее голословны.

Что касается позиций, то я лично наблюдаю другую картину.

Фанат плюсов:

- Вот все говорят о дотнете, а ведь это полная туфта. На нем же даже игрушку написать нельзя.
— Помилуйте, вот игршка. Загрузите, поглядите.
— Но на нем же даже софт-риалтайм системы невозможно создать. Причем принципияльно!
— А вы их создаете?
— Я, нет. Но все же.
— Кстати, вот сообщение о выпуске конторой ХХХ софтреалтайм-рантайма для Явы, а вот описание разработки того же самого для дотнета.
— Да? Наверно это фигня. Да и ведь не хард! Ну, тогда ЖЦ торомзит. Пример — Янус. У меня при считавании сообщений иногда тормоза. И при переключении веток тоже.
— По милйте, откройте любой профайлер и вы увидите, что ЖЦ не оказывает никакого влияния на скорость наботы Януса. Например, у меня время проведенное в ЖЦ составляет 0.02%. При открытии сообщения, Янус лезет в БД через JET, считывает строку и передает ее в IE-контрол. И JET, и IE — это анменеджед-контролы написанные на С++. Так что тормоза Януса являются чисто алгоритмическими и уж скорее могут быть ассоциированы с С++.
— А...А...А, тогда дотнет жрет очень много памяти!
— Насколько много?
— Вот янус жрет 60 метров.
— А сколько у вас ее всего?
— Гиг.
— И это вам мешает?
— Мне нет, но все же. К тому, же дотнет интерпретатор, вот поглядите как в янусе переключаются сообщения.
— Помилуйте, дотнет джитер.
— Да какая разница?
— Дык, он порождает компилированный код который мало чем отличается от порождаемого средним С++-компилятором.
— А...а...а, вот еще у дотнета есть куча рантайм-проверок.
— Да есть, но она делаются не всегда и часто оптимизируются. В итоге сумма оверхэда и отсотвания оптимизатора редко позволяет С++-коду обогнать управляемый больше чем на 20%. Плюс к тому же всегда есть возможность при крайней необходимости воспользоваться небезопасным кодом и породить такой же кода как на С++/С.
— А какой же тогда смысл в C#?
— Дык, оптимизировать нужно очень малый объем кода. А остальной при этом пишется проще и быстрее.
— Нифига не проще!
— Да, как же не проще? Я вот писал на С++ и после перехода на дотнет и C# по пошествию некоторого времени начал работать намного продуктивнее.
— А мой опыт показывает, что нифига на C# писать не быстрее.
— А вы пробовали.
— Да! Я попробовал писать на C# "Дарова, мир!", поплювался на непривычных синтаксис и бросил.


Короче, этот рассказ можно продолжать еще долго.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: С++ culture
От: vdimas Россия  
Дата: 17.11.05 21:43
Оценка: 37 (5) +2 -1
Здравствуйте, VladD2, Вы писали:

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

И насчет инноваций — неплохо тебе ознакомится с JavaMe, и конкретно с устройствами, типа @Blackberry. Тогда мы сможем поговорить о степени инноваций.

VD>В общем, я не против обсудить эту тему. Но объяснять все с нуля не буду. Как минимум я не имею должной компитенции, а вопрос разянен в тонне статей доступных в Интернете. Так что если хочешь конструктива, прочти любое введение.


Я вот только одного не понимаю, почему когда я пытаюсь развить тему привязки HAL к железу и уровне его абстракции, ты отсылаешь меня к микроядерной архитектуре??? Еще при этом пытаешься выставить за ламера. Я реально имел дело с совершенно различными по уровню HAL, и знаю о чем говорю. Понятие HAL никак не пересекается с архитектурой ОС.

Более того, если ты уж так подробно интересовался микроядерной архитектурой, то ты должен прекрасно понимать, что для микроядерной архитектуры требуется самый что ни на есть высокий уровень абстракции от железки. Ибо в микроядерной архитектуре общение с драйверами происходит наиболее затратно, т.е. наличие лишнего драйвера дорогого стоит. Именно из-за этой затратности эра микроядерных архитектур еще не наступила, скорее всего будет рулить еще один класс, помимо монолитных и микроядерных, о которых ты не упомянул — различные смешанные архитектуры. Конкретно, новая BSD, которую пишут на именно на основе микроядра, все же не будет полностью микроядерной. Необходимо будет делать некие компромиссы. Компроммисы уходят либо в HAL (что проще), либо в "монолитные" драйвера, что чуть сложнее, т.к. потребует от операцинки поддерживать 2 модели драйверов, "внешних" и "внутренних".

Именно поэтому я и считаю, что для каждой новой железки для этой Сингулярити придется приличную часть НЕПЕРЕНОСИМОГО кода по-любому писать в unmanaged.

Тут я кое-что ответил Синклеру, не хочу повторяться http://www.rsdn.ru/Forum/Message.aspx?mid=1494189&amp;only=1
Автор: vdimas
Дата: 18.11.05


----------
И по поводу моего незнания C#. А-я-яй опять дергать из контекста. Я говорил про прямой доступ не только к памяти, но и к портам и прерывания. Работа с прерываниями — это задание своих точек входа на обработчики. Я спрашивал — возможно ВСЕ это? НЕТ. На C# вряд ли можно написать корректную точку входа для обработки прерывания для конкретного проца. Т.е. в ф-ии HAL помимо всего того, что прочтешь по ссылке выше, надо будет добавлять нечто вроде SetStaticMethodAsIRQEntry, это тянет за собой еще одну проблему — надо обеспечить, чтобы указанный метод был явно загружен джитом, ибо обработка прерываний по сути должна иметь быструю реакцию, а не ждать, пока джит что-то там разджитит, т.е. в API надо добавлять еще методы по явному управлению VM (пусть даже во внутренние API OС).

В общем, когда они дойдут до более-меннее реальной системы и откроют всю информацию по ней, тогда можно будет судить, что именно и где managed, а где нет.

Простое заявление "у нас драйвера на C#" говорит слишком мало.
Re[10]: С++ culture
От: Cyberax Марс  
Дата: 15.11.05 14:56
Оценка: +4 :))) :)
Lazy Cjow Rhrr wrote:

> А что собственно "бррр"? И тем более чем не угодил первый вариант? И

> наконец, может есть третий вариант, который лучше их обоих?

MyRAII1 r1;
MyRAII1 r2;
MyRAII1 r3;
MyRAII1 r4;



--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[11]: С++ culture
От: Павел Кузнецов  
Дата: 09.11.05 13:59
Оценка: 24 (4) +3
mrozov,

> То, что я в меньшинстве со своим пониманием опасности вызова CreateThread, я-то как раз прекрасно понимаю. А вот Вы в своей башне из слоновой кости бум web-программирования, похоже, благополучно проспали. Мир изменился.


Вы совершенно зря юродствуете. "Бум web-программирования" нас затронул по полной программе: почти половина команды у нас пишет на C# именно под web. Но web-программирование, покрывающее в нашем случае часть use cases, совершенно не отменяет необходимости в клиентских программах, устанавливаемых на компьютеры пользователей, равно как и в серверных программах. И эти разновидности программ мы пишем на C++. Да и в "большом" web-программировании далеко не все так однозначно: примерами тому могут служить Google и Amazon, значительная часть кода которых -- C++.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[8]: С++ culture
От: remark Россия http://www.1024cores.net/
Дата: 04.04.08 13:03
Оценка: 1 (1) :))) :))
Здравствуйте, VladD2, Вы писали:


VD>Все же Ява и С++ это языки исповедующие разные парадигмы. Ява компонентный и динамический язык с минималистическим синтаксисом, а С++ статический (не компонентный) и монструозный.



С++ — статический язык, со статической типизацией, потому что С++ программы зачастую пишуться, что бы выполняться без присутствия программиста.




1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.05 00:50
Оценка: :))) :)))
Здравствуйте, Павел Кузнецов, Вы писали:

...
sch>Долой вражду на основе языков программирования.
sch>Да здравствует языковый космополитизм.
...
ПК>Будет ли один и тот же человек одинаково производительным, пользуясь разными инструментами?

Щаз спою... (с)
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: С++ culture
От: Joker6413  
Дата: 11.11.05 07:53
Оценка: +6
Здравствуйте, Ligen, Вы писали:

Странные выводы из пространной болтовни.

.Net по большому счету это что? Enteprise level, а C++ — это довольно низкий уровень. Ниши использования давно сформировались, имеют довольно четкое разделение и существуют параллельно.
Скорую смерть C++ пророчили еще в середине 90х, когда борланд выпустил дельфю. Стоит ли говорить, что заявлять такое могли только те кто реально в C++ проектах не работал. Сейчас можно оценить качество их предсказаний.
Я давно ушел на .net, но считаю, что кандидата на титул "убийца С++" в обозримом будущем не наблюдается.
Re[10]: С++ culture
От: Павел Кузнецов  
Дата: 16.11.05 01:56
Оценка: +6
On Tue, 15 Nov 2005 18:41:01 -0600, VladD2 <73@users.rsdn.ru> wrote:

> Здравствуйте, vdimas, Вы писали:

>
> V>Проблемы скорее оформительского плана:
> V>
> V>using (MyRAII1 r1 = new MyRAII1())
> V>    using (MyRAII2 r2 = new MyRAII2())
> V>        using (MyRAII3 r3 = new MyRAII3())
> V>            using (MyRAII4 r4 = new MyRAII4()) {
> V>                ...
> V>                ...
> V>            }
> V>

> V>Даже в таком написании глаз не то чтобы радовал...
>
> Ты бы хоть ради хомхмы прежде чем излагать свои теории на людях зашел бы в студию и попробовал написать этот код в ней. Она бы тебе сразу отформатировала код следующим образом:
>
> using (MyRAII1 r1 = new MyRAII1())
> using (MyRAII2 r2 = new MyRAII2())
> using (MyRAII3 r3 = new MyRAII3())
> using (MyRAII4 r4 = new MyRAII4())
> {
>     ...
>     ...
> }
>

> И никаких проблем.
>
> Собственно налог на плюсах будет примерно такой:
>
> {
>     MyRAII1 r1 = MyRAII1();
>     MyRAII2 r2 = MyRAII2();
>     MyRAII3 r3 = MyRAII3();
>     MyRAII4 r4 = MyRAII4();
>     {
>         ...
>         ...
>     }
> }
>


А зачем мусор в правой части? И зачем скобки после r4?
{
    MyRAII1 r1;
    MyRAII2 r2;
    MyRAII3 r3;
    MyRAII4 r4;
    ...
}

Плюс, если автор пишет короткими функциями, окружающие скобки скорее всего будут скобками функции, содержащей данный код.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[10]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.11.05 07:16
Оценка: 37 (3) +2
Здравствуйте, VladD2, Вы писали:

E>>Влад, извини, что увожу тему в сторону, но почему ты считаешь Java динамическим языком?


VD>Вообще-то его таковым считали авторы еще при создании.


Понятно, значит классификацию Java как динамического языка нужно оставить на совести его создателей

VD>А вообще, что тут считать то? Язык позволяет делать динамически все от загрузки объектов, до компиляции.


А вот если попробовать подсчитать, то можно интересный результат получить (http://en.wikipedia.org/wiki/Dynamic_programming_language):

In computer science, a dynamic programming language is a kind of programming language in which programs can change their structure as they run: functions may be introduced or removed, new classes of objects may be created, new modules may appear.


Можно ли в Java вводить новые методы в уже существующие классы? AFAIK, нет.
Можно ли в Java изымать существующие методы из уже существующих классов? Опять же, AFAIK, нет.

Подгружать новые модули с новыми классами и объектами? Да ты же сам мне недавно доказывал, что через COM на C++ это уже давно можно было делать.

Компилировать новые модули и подгружать их в уже работающую программу? Да на C++ -- нет проблем: запускаем внешний компилятор, строим DLL и полный вперед. А если компилятор оформлен в виде DLL или COM-объекта, то прямо из приложения можно это делать.

Единственное проявление динамизма Java, которое приходит мне в голову -- это возможность вызова либого метода объекта через reflection с передачей аргументов в виде object[]. Только, имхо, маловато этого, чтобы динамическим языком называться. Поэтому, как мне кажется, динамизм некоторых языков сильно преувеличивается.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: С++ culture
От: vdimas Россия  
Дата: 16.11.05 12:16
Оценка: 30 (2) +2 :)
Здравствуйте, mrozov, Вы писали:

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

Например:
— смарт поинтеры используем только такие-то и такие-то (как правило один интрузивный, один неинтрузивный и один авто)
— запрещается помещение результата операции new в голый указатель, кроме случаев, где этот указатель является закрытым членом типа, но в любом случае рекомендуется делать эти указатели в виде смарт-поинтеров.
— при разработке проколов взаимодействия объектов четко специфицировать отношение владения/использования. Граф зависимостей, отображающий отношение владения может быть только однонаправленным.
— специфицируются либы и способы их использования, скажем, для обратных вызовов используется такая-то либа (сейчас буст популярен), для строк и прочих агрегатов — такая-то (обычно STL, но порой коряво сопрягается в MFC/ATL проектах, проще использовать их... Под эти строки/коллекции иногда пишут свои специализации как бинд на алгоритмы STL

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

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

Скажу честно, что и я уже очень давно не помню проблем с утечками или падениями. Использование всяких auto_value, смарт-поинтеров, заведомо надежных библиотек и просто стандартной библиотеки, во первых, делает код ГОРАЗДО короче, во вторых, настолько же безопаснее. Свой код надо складывать из заведомо надежных и отработанных кирпичиков.


Разумеется, бывают места, где приходится поупражняться с битами. Но, во первых, этих мест в реальных проектах очень мало (маленький % по отношению к остальному коду), во вторых, эти места обычно тщательно изолируют от прямого использования.

Если С++ команда работает без четких выработанных внутренних стандартов, то естественно, проблемы могут возникать у кого угодно, и "сверестественный" проффесионализм здесь не при чем. Профессионализм должен проявляться в организации своего труда, в первую очередь, остальное — во многом лишь следствие.
Re[10]: С++ culture
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.11.05 08:50
Оценка: 8 (1) +4
Здравствуйте, GU Glez, Вы писали:

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


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

GG>А что мы имеем в программировании. Мало того что по идее надо бы знать пяток-десяток другой ЯП и Технологий, так еще и следить за их движением в области развития, которое происходит довольно таки часто.


Пяток-десяток не надо, надо характерных представителей того или иного направления.

GG>В университете писал на Asm, C (C++ — не признавал по идеологиским соображениям), Delphi и FreePascal.


Это все языки одного порядка (разве что asm немножко выбивается).

GG> Начиная с 3-го курса проводил переодически мастер-класс для некоторых преподавателей (извините за нескромность, далее по тексту Вы поймете о чем речь). Однако, сейчас я не могу без отрывы от производства сесть и сделать тоже самое как на Delphi, так и на VC++.


Это тоже языки одного порядка. И то, что тебе потребовалась ломка сознания как раз и показывает, что ты был не способен легко взглянуть на проблему даже с немножечко другой стороны, не говоря уж о ортогональных подходах. И изучение этих самых других подходов, даже если ты их потом применять не будешь, очень упростит в дальнейшем жизнь.
... << RSDN@Home 1.2.0 alpha rev. 619 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[3]: С++ culture
От: sch  
Дата: 20.10.05 08:57
Оценка: 6 (1) +3 :)
sch>>А я вот честно говоря не понимаю причин, по которым спорят о преимуществах одних языков над другими языками, одних API над другими API, одних компиляторов над другими компиялторами. По моему скромному мнению, профессионал может работать с любыми языками, средставами, API, девкитами и прочим; все что нужно, для того, чтобы быть производительным -- компьютер, тишина и немного кофе.
Ч>Разве не хочеться выбрать средство для работы поудобнее?

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

Соответственно, больше всего пугает самое новое и необычное: например, чаще всего у C++ программистов нарекания вызывает GC из .NET. Боже мой, он будет лазить по моим структурам когда ему захочется, и будет освобождать память!
Сам!


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

GC из .NET -- не ужасен, просто он несколько другой. Именно это и пугает.

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

Как говорил один замечательный художник и просто умный человек: причиной любого конфликта является непонимание.
Re[9]: С++ culture
От: vdimas Россия  
Дата: 17.11.05 22:19
Оценка: 2 (2) +3
Здравствуйте, mrozov, Вы писали:

M>Здравствуйте, vdimas, Вы писали:


V>>Согласен. Дотнет отберет прилично задач не только у Явы, но и у С++. Ну и на здоровье. Самое правильное — использовать наиболее подходящий инструмент для каждой задачи. С++ приобретет легкий оттенок "системного" языка, а про С мы наверно забудем.


M>Я тут, собственно, именно об этом и говорю. А меня бьют лопатами.


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

Опять же, во многих конторах уже накопилось весьма и весьма объемные и функциональные наработки на том же С++, т.е. вполне возможна ситуация, что некоторый класс даже заказных разработок будет выполнен быстрее и качественнее с применением обкатанных наработок, чем на .Net. Т.е. вопрос "целесообразности" — это такой многофакторный вопрос, и действительно, чей-то конкретный опыт не обязательно хорошо ложится на общий случай. Тебя "били лопатами" те, у кого дело примерно так и обстоит.

Поясню. В наработки входят не только либы/решения. Конторы "обрастают" всевозможными самописными тулзами и целыми интегрированными системами/надстройками. Т.е. в поддержание самого процесса целевых разработок было вложено немало сил, и эти вложения все еще неплохо себя оправдывают. Начинание с 0-ля может быть болезненным.

Для .Net только буквально к 2004-2005-му году сформировался достаточный список вспомогательного инструментария/либ. Многие весьма платные. Например, в Java ситуация пока что гораздо интереснее и больше свободы выбора.

В общем, посмотрим еще через годит на обстановку.
Re[6]: С++ culture
От: mrozov  
Дата: 08.11.05 10:49
Оценка: 1 (1) +2 -2
Здравствуйте, eao197, Вы писали:


E>Скорость написания кода, это еще не все. В Java, когда мне приходилось ей заниматься, было множество своих заморочек, которые отрицательно сказывались на скорости написания кода. Плюс, для некоторых типов задач, у Java была очень низкая скорость исполнения кода. Так что с Java у меня не сложилось.


Я так думаю, что это было давно? Java развивалась весьма сильно с каждой версией. В любом случае, c# заметно поудобнее и код получается быстрым везде, где мне это удавалось увидеть.


E>Но ведь речь нужно вести о конкретных командах и конкретных проектах. Если есть команда, хорошо владеющая C++ и не допускающая того количества ошибок, о котором постоянно говорят, и эта команда специализируется в конкретной предметной области, имеет в ней свои наработки, то почему участники этой команды не могут агитировать за C++? Я вот этого не понимаю.


У меня есть проекты, написанные на с++, нуждающиеся в поддержке, и навыки, для этого необходимые. Я не пытаюсь переписывать их на .net. Но
и агитировать в пользу с++ не стал бы. Почему — написано выше и ниже еще добавлю.

E>Т.е. лозунг "Все в .Net или Java!" -- это легально. А вот "Пишите прикладные проекты на C++" -- это уже нецензурная брань? Так получается?


Именно так и получается. Массовая распространенность с++ — трагическое недоразумение. Впрочем, насколько я понимаю, это почти чисто российский феномен. Ведь с++ это так круто! Ведь все конкретные пацаны только на нем и пишут. VB — он для слабаков! А кто же из молодых и зеленых хочет быть слабаком?

Слава богу, что .net предложил хорошую альтернативу. Хорошую, замечу, почти во всех направлениях, и в большинстве — лучшую. c++ все равно нужен? Да. Заинтересовано ли общество в том, чтобы сишного кода было побольше? Не думаю.

Вам, я так понимаю, за "державу" обидно? Так это эмоции. Конечно, золотое правило "не ломалось — не чини" никто не отменял. Конечно, все бросать не нужно. Но и избыток гордости за выбранное профессиональное направление человека, имхо, не красит.
Re[7]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.11.05 11:17
Оценка: 1 (1) +4
Здравствуйте, mrozov, Вы писали:

E>>Скорость написания кода, это еще не все. В Java, когда мне приходилось ей заниматься, было множество своих заморочек, которые отрицательно сказывались на скорости написания кода. Плюс, для некоторых типов задач, у Java была очень низкая скорость исполнения кода. Так что с Java у меня не сложилось.


M>Я так думаю, что это было давно? Java развивалась весьма сильно с каждой версией. В любом случае, c# заметно поудобнее и код получается быстрым везде, где мне это удавалось увидеть.


Да, давно.
А с C# ты будешь себя хорошо чувствовать только на MS-платформах, либо ждать, пока Mono будет пытаться за MS успеть.
Если сейчас нужна кроссплатформенность, то выбор реально есть либо из C++, либо из Java, либо из любого динамического языка (вроде Perl, Python или Ruby).

M>Слава богу, что .net предложил хорошую альтернативу. Хорошую, замечу, почти во всех направлениях, и в большинстве — лучшую. c++ все равно нужен? Да. Заинтересовано ли общество в том, чтобы сишного кода было побольше? Не думаю.


Имхо, общество -- это понятие абстрактное.

Лично я заинтересован, чтобы качественного C++ кода было побольше. Я уже не общество?

M>Вам, я так понимаю, за "державу" обидно? Так это эмоции.


А "все на .Net" -- это не эмоции?
При том, что сопутствующего софта для Java сейчас на порядки больше, чем для .Net. Одних IDE, если только подсчитать

M> Конечно, золотое правило "не ломалось — не чини" никто не отменял. Конечно, все бросать не нужно. Но и избыток гордости за выбранное профессиональное направление человека, имхо, не красит.


А перепрыгивание с технологии на технологию только из-за моды (конкретно на RSDN, здесь и сейчас, популярен .Net) так же не красит. Здесь вообще сильны две эмоции -- "С++ дырявое решето, поэтому must die!" и ".Net -- наше все, поэтому все в .Net". Странно, что Java никто не продвигает. Хотя сейчас это уже гораздо более проработанная платформа, чем C#.

В общем, мне кажется, что лозунги "Нужно писать на .Net, потому, что C++ глючный, т.к. я на нем пишу с ошибками" -- это такая же эмоция, как "C++ forever!". А выбор языка и платформы для конкретной задачи должен включать в себя анализ большого количества факторов. И очень жаль, что критерий "количество багов в C++ программах" для конкретной команды оказывается на одном из первых мест.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: С++ culture
От: Павел Кузнецов  
Дата: 19.10.05 16:30
Оценка: +4 :)
sch,

> А я вот честно говоря не понимаю причин, по которым спорят о преимуществах одних языков над другими языками, одних API над другими API, одних компиляторов над другими компиялторами. По моему скромному мнению, профессионал может работать с любыми языками, средставами, API, девкитами и прочим; все что нужно, для того, чтобы быть производительным -- компьютер, тишина и немного кофе.


Будет ли один и тот же человек одинаково производительным, пользуясь разными инструментами?
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[2]: С++ culture
От: Чипсет Россия http://merlinko.com
Дата: 20.10.05 04:29
Оценка: :))) :))
Здравствуйте, sch, Вы писали:


sch>А я вот честно говоря не понимаю причин, по которым спорят о преимуществах одних языков над другими языками, одних API над другими API, одних компиляторов над другими компиялторами. По моему скромному мнению, профессионал может работать с любыми языками, средставами, API, девкитами и прочим; все что нужно, для того, чтобы быть производительным -- компьютер, тишина и немного кофе.

Разве не хочеться выбрать средство для работы поудобнее?
sch>Поймите меня правильно. Я программирую на C++, я люблю этот язык, знаю его норов, знаю тонкости его использования. Но если завтра мне будет нужно писать на C# -- я буду писать на C#, если будет нужно писать на Java -- буду писать на Java, а каким красивым и изящным может быть код на GW-BASIC... По моему скромному мнению, новый язык -- это здорово: можно взглянуть на кажущиеся неприступными истины.

Мне особенно нравиться Brainfuck.

sch>Долой вражду на основе языков программирования.

sch>Да здравствует языковый космополитизм.

Таки да. Ну вот и я учу Java, и даже Влад учит C++ и по слухам, он ему очень нравиться но он стесняеться в этом признаться
... << А писал я этот бред на RSDN@Home 1.1.4 stable rev. 510, под звуки ДДТ — Tы будешь вечно>>
"Всё что не убивает нас, делает нас сильнее..."
Re[4]: С++ culture
От: mrozov  
Дата: 08.11.05 09:48
Оценка: +3 -2
1. Не хочу показаться грубым — я не обвиняю Вас во лжи. Но мне лично программисты Вашей квалификации никогда не встречались. Я лично, работая с с++, разнообразных проблем, прямо или косвенно связанных с неверными указателями объелся просто. Утечки памяти имели место быть практически в каждой написанной мной программе.

2. Подозреваю, что даже такой высококлассный специалист, как Вы, смог бы выиграть в скорости написания кода той же степени надежности, используя не с++, а с# или Java.

3. Желательно все-таки читать написанный текст, а не бороться с собственными демонами. Я в своем посте помянул именно и конкретно то, что вижу своими глазами регулярно. А именно — массу проблем, связанных с использованием с++ теми, кто рожден для программирования на VB.

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

Для меня лично переход на .net ознаменовал резкий скачек в производительности работы. Не в последнюю очередь за счет Resharper-а, NUnit-а и xml-comments. Обратно — не хочу.

Dixi.
Re[8]: С++ culture
От: mrozov  
Дата: 08.11.05 11:45
Оценка: +2 -3
E>А перепрыгивание с технологии на технологию только из-за моды (конкретно на RSDN, здесь и сейчас, популярен .Net) так же не красит. Здесь вообще сильны две эмоции -- "С++ дырявое решето, поэтому must die!" и ".Net -- наше все, поэтому все в .Net". Странно, что Java никто не продвигает. Хотя сейчас это уже гораздо более проработанная платформа, чем C#.

Java — рулит. Но у нее есть фатальный недостаток — ее создал не MS. Причем я не шучу.

E>В общем, мне кажется, что лозунги "Нужно писать на .Net, потому, что C++ глючный, т.к. я на нем пишу с ошибками" -- это такая же эмоция, как "C++ forever!". А выбор языка и платформы для конкретной задачи должен включать в себя анализ большого количества факторов. И очень жаль, что критерий "количество багов в C++ программах" для конкретной команды оказывается на одном из первых мест.


Да нет же, все не так. Нужно писать на .Net, потому, что C++ глючный, т.к. я, все мои знакомые программисты и подавляющее большинство других программистов, на нем пишут с ошибками. А количество ошибок на .net заметно меньше, как и общая скорость разработки. И практика моей компании показывает, что стоимость решений на с++ оказывается неприемлимо высокой.

Короче — если мыслить с позиции человека, который отвечает за разработку, то выбор очевиден. C++ только там, где этого нельзя избежать.
Из любого правила есть исключения, но общая тенденция такова.

А вообще, у меня есть друг, в чем-то похожий (видимо) на Вас. Только он не сишник, он уже много лет на скриптовых языках пишет. Очень грамотный и очень одаренный товарищ, золотые руки.
Вот ему .net не нужен. И с++ ему тоже не нужен. И от строгой типизации он видит один вред.

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

И за долгие и многочисленные часы нашего общения на эту тему мне так и не удалось довести до его сознания простую мысль — он в меньшинстве и распространять свой опыт на окружающих автоматически — совершенно некорректно. Вас мне убедить тоже, очевидно, не удастся.
Re[9]: С++ culture
От: Павел Кузнецов  
Дата: 08.11.05 14:43
Оценка: +5
mrozov,

> Нужно писать на .Net, потому, что C++ глючный, т.к. я, все мои знакомые программисты и подавляющее большинство других программистов, на нем пишут с ошибками. А количество ошибок на .net заметно меньше, как и общая скорость разработки. И практика моей компании показывает, что стоимость решений на с++ оказывается неприемлимо высокой.


Это ваш опыт. Не пытайтесь его обобщать в категоричной форме на всех.

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


Зря вы не применяете этого же подхода к себе.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[12]: off
От: mrozov  
Дата: 10.11.05 10:57
Оценка: 31 (3) +1
Здравствуйте, Геннадий Васильев, Вы писали:

Коллега, я надеюсь, что Вы не сочтете это за оскорбление, но Вы нудите.
Хотите, я разберу Ваш пост по косточкам и высмею каждую фразу, которую Вы написали? Причем это будет совсем несложно.

Доказывать я что-то буду коллегии присяжных, да и то — только по совету моего адвоката. Я делюсь своим опытом и опытом моих коллег, которых я знаю лично. Мои оппоненты делают в точности то же самое. Я почему-то не заметил, чтобы Вы потребовали доказательства репрезентативности их выборки.

Просто так уж сложилось, что за 10 лет практики я ни разу не столкнулся с задачей, которая требовала бы задействования тех преимуществ языка с++ над java/.net, которые действительно в реальности существуют, причем требовала бы не локально, не в двух-трех местах, а повсеместно.

Одно из приложений, которое сейчас находится у меня в разработке, написано на смеси c++ и с#. Просто для решения одной из подзадач с++ оказался удобнее. Но подзадача — сравнительно мелкая и легко изолируемая.
Другое приложение, оптимизацией которого я в данный момент занимаюсь, написано уже чисто на с++. Обусловлено это особенностями конфигурации машин потенциальных клиентов, а вовсе не преимуществами с++. .net, как раз, был бы гораздо удобнее. И так далее и тому подобное. Причем в моей практике таких нюансов встречается на порядок больше, чем у большинства людей, с которыми я когда-либо работал.

Все это ни в малейшей степени не означает, что "жирафов не бывает". Разумеется, есть люди, которые исключительно такими задачами и занимаются. Просто мой личный (и не только мой) опыт заставляет меня крайне скептически относиться к предположениям, что таких задач — большинство. Доказательств обратного, замечу, мне никто (включая Вас) не предоставил.

Имею ли я право на свое мнение? Думаю, что да. Имеет ли мое мнение под собой веские основания? Думаю, что да. Прав ли я? Возможно, нет. Но пока мой подход себя оправдывал. Чего и Вам желаю.
Re[3]: С++ culture
От: sch  
Дата: 20.10.05 08:44
Оценка: 22 (3) +1
ПК>Будет ли один и тот же человек одинаково производительным, пользуясь разными инструментами?

Одинаково ли хорошо звучит La Divina Commedia на русском, итальянском, китайском? Понятно, что разброс есть, но он зависит как от экспрессивности языка, так и от мастерства переводчика. Собственно говоря здесь наблюдается полная аналогия с программированием.

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

Так что...


Nel mezzo del cammin di nostra vita
mi ritrovai per una selva oscura
che' la diritta via era smarrita.


...равнозначно...


Земную жизнь пройдя до половины,
Я очутился в сумрачном лесу,
Утратив правый путь во тьме долины.


...вся разница -- в экспресии!
Re[14]: полный off
От: mrozov  
Дата: 11.11.05 12:16
Оценка: 19 (3) +1
Ох. Тяжело это все-таки.

Но! Одну фразу я все-таки прокомментирую. Умоляю — не надо мне отвечать.

ГВ>Не хотите — не доказывайте, Ваше право. Но и не ждите серьёзного отношения к бездоказательным (сиречь — голосоловным) утверждениям.


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

Могу дать еще один безапеляционный совет. Тоже следующий из моего личного опыта и абсолютно бездоказательный.

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

Если выясняется, что собеседник имеет свою четкую позицию. в корне отличную от моей — я вступаю в спор и выкладываю свои аргументы. Внимательно выслушиваю аргументы другой стороны. Дискуссия прекрашается, когда я понимаю, что:
— позиция и аргументация собеседника мне понятны
— консенсус найден или не кажется достижимым за разумный период времени

Выхожу из такого разговора я, обогащенный новыми знаниями и расширившимся взглядом на мир. Надеюсь, что это же можно сказать и о моих собеседниках. Хотя это и не главная цель.


Вышеописанный алгоритм на основании личного опыта считаю оптимальным. Выдирание чужих фраз из контекста, произвольная их трактовка и аргументация в стиле "вот тут вы меня не убедили, а значит вся ваша позиция неверна", предсталяются мне черезвычайно неуважительным, а главное — бессмысленным способом общения. Я ведь все еще имею право на свою точку зрения, правда?


Всего доброго.
Re[4]: С++ culture
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.11.05 14:25
Оценка: 9 (1) +2 -1
Здравствуйте, VladD2, Вы писали:

ГВ>>И хотя я могу показаться крамольным... Тем не менее, следует учитывать, что язык в немалой степени определяет способ мышления. Хотя, если задача, или ещё какие-либо условия мышления не требуют, то спору нет, в таком контексте бессмысленно говорить о различиях языков, API и прочих подобных вещей.


VD>Язык определяет сужение мышления. Люди знающий один ЯП принципиально не могут мыслить широко(Выделение и сопутствующий гомерический хохот мои. — ГВ). А вот когда ты знашь много разных языков, то на любом языке ты можешь мысль более свободно.


Не согласен. Свобода изложения мысли складывается из:

— понимания цели (задача + контекст);
— наличия мысли;
— владения средством изложения мысли.

Это всё, что необходимо. Хотя я не буду спорить с тем, что знакомство с подходами, предлагаемыми другими языками (API и пр.) может помочь в том смысле, что подскажет какой-то незатёртый ход, идею и т.п. Но само по себе оно не определяет ни широты мышления, ни уровня абстракции излагающего. Более того, может даже мешать (ты и сам по этому поводу много высказывался ).

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

ГВ>>Только не забудь, плз., что: "Я программирую на C++, я люблю этот язык, знаю его норов, знаю тонкости его использования". А теперь вспомним, наследниками культуры какого-конкретно-языка являются и Java, и C#.


VD>И какого же? У Явы дцать родителей. У Шарпа не меньше. Или схожесть синтаксиса определяет все что можно?


C++, разумеется. Он есть в родителях Java? Есть. С чего начинается изучение языка? С синтаксиса. Синтаксис близок к C++? Ещё как близок! Семантика бОльшей части операторов и объявлений близка к C++? Ещё как близка! Дык, для какой группы программистов облегчён переход на Java? Правильно — для C++-ников. Что они принесут? Правильно, мутировавшую C++-культуру. Ergo, "Java-культура" в немалой степени наследует C++-культуру и именно её!

Точно такая же наследственность у C#. Только его, правда, в кашу превратят скоро, но сейчас это к делу не относится.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[15]: С++ culture
От: Kluev  
Дата: 10.11.05 16:32
Оценка: 2 (2) +2
Здравствуйте, VladD2, Вы писали:

K>>Самому не смешно?


VD>А что мне смеяться то?


K>>А нужно всего-то:

K>>
K>>struct Triangle
K>>{
K>>   Node *nodes[3];
K>>   Node* node_at( int idx ) // кольцевой доступ
K>>   {
K>>      static const int imap[] = { 1, 2, 0, 1, 2, 0, 1 };
K>>      return nodes[imap[idx+2]];
K>>   }
K>>};
K>>


VD>За такой код в промышленных системах нужно по началу лишать премий, а потом выгонять если не прочувствушь. Это называется начхание на инкапсуляцию.


А что инкапсуляция это догма? К тому же не везде она хорошо работает. Например есть устовшаяся структура данных, а алгоритмов вокруг нее пишется тьма. В этом случае инкапсуляция совершенно неуместна

К примеру, такой подход:
struct Shell; // устоявшийся, редко меняемый класс

void shell_make_watertight(Shell *p, double tolerance); // непрерывно в разработке
// и еще куча функций вокруг, которые добавляются-выбрасываются в процессе

Гораздо лучше чем:
class Shell
{
 // триста функций на борту
};



VD>Написать аналогичный по объему и безобразию код никаких проблем нет. Выкинь из примера все и оставь тольео индексатор. Получится тоже самое.


Node* node_at(int idx)
{
   switch (idx)
   {
     case -2: return &node1;
     case -1: return &node2;
     case  0: return &node0;
     case  1: return &node1;
     case  2: return &node2;
     case  3: return &node0;
     case  4: return &node1;
   }
}

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

VD>Код этот один фиг пишется один раз на проект. И жалеть тут 20 строк смысла нет.

И эти 20 строк еще в 15-ти местах.

VD>Лучше уж иметь более защищенную и удобную систему. А вот использование будет полностью идентично.

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

VD>>>А можно применить ансэй и будет точно так же как на плюсах. Если при этом как следует инкапсулировать опасный код, то дальше можно работать совершенно безопасно.


K>>А почему бы тогда сразу не на плюсах? Зачем какие-то танцы с бубном.


VD>Потому что оптимизации требует отдельные, редко встречающиеся кусти кода, а безопасность и скорость разработки нужны везде.

Ты что же, девелоперов за лохов держишь? Еслибы С# ускорил и обезопасил мой процесс я бы нанего и перелез. А так пока я вижу, что только прийдется заниматся обходом всяких геморов и лишатся удобств.
Re[4]: С++ culture
От: Cyberax Марс  
Дата: 20.10.05 09:08
Оценка: 1 (1) +2 -1
sch wrote:

> Соответственно, больше всего пугает самое новое и необычное: например,

> чаще всего у C++ программистов нарекания вызывает GC из .NET. /Боже
> мой, он будет лазить по моим структурам когда ему захочется, и будет
> освобождать память! Сам!/

Это-то фигня. Больше всего раздражает, что GC уничтожает память
недетерминировано. А значит RAII и подобные идиомы не проходят.

> GC из .NET -- не ужасен, просто он несколько /другой/. Именно это и

> пугает.

GC? Пугает? Хахахахаха.....

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 2.0 beta
Sapienti sat!
Re[12]: С++ culture
От: mrozov  
Дата: 08.11.05 14:08
Оценка: 1 (1) +1 -1 :)
Здравствуйте, Kluev, Вы писали:

K>А CAD — не прикладное программирование?


Речь идет о миллионах людей, перед которыми такие задачи никогда не встанут. Против тех тысяч, которые вынуждены иметь с ними дело.
Вы знаете, сколько в мире программистов на VB/Delphi? Сколько web-программистов? Вы мне говорите о капле в море, которую пытаетесь возвести в закон. Понимания в моем лице, естественно, не добиваясь.

K>>>Только исключений слишком много.

M>>Я вижу очень мало. А я по меркам большинства моих коллег — хардкорщик.
K>Реальность это больше чем мы видим. А мерки вещь очень относительная. Для кого-то и VB-шник хардкорщик.

Именно! О том, собственно, и речь. Большую часть своей карьеры я занимался как раз тем, что разрабатывал низкоуровневые компоненты для программистов, которые сами от таких вещей далеки. Я этим занимался в разных компаниях. Забавно, что для многих профессиональных программистов умение написать сервис или знание основ многопоточного программирования выглядит мистическим шаманством.

Вы, вероятно, посчитаете их просто недоучками... точно также, как они посчитают (вероятно) недоучкой Вас, раз Вы плаваете в тонкостях CSS и не в состоянии без запинки сказать, в чем отличия IE версии 5.0. от 5.5 (примеры взяты от балды и к реальным Вашим знаниям, разумеется, отношения не имеют). И заметьте, будут на 100% правы.

Отойдем чуть в сторону и что же мы видим? Ба, да это же Java-программисты! Которые Вам с удовольствием расскажут, насколько велика их доля рынка и насколько нелепо Вы будете смотреться, пытаясь написать application layer средненькой такой корпорации на с++.

Автоматизация бухгалтерии? Обработка excel-евских файлов на с++? Удачи. Она Вам понадобится.

web-приложение?

Таких примеров — вагон и маленькая тележка. Ни один разумный человек не станет убеждать окружающих в том, что драйвера нужно начинать писать на C#. И я искренне надеюсь, что не за горами времена, когда люди будут стесняться предлагать писать бизнес-логику или, скажем, UI, на с++.

K>И в чем же аргумент? сам хоть понял что сказал?

Многоуважаемый коллега! Позволю себе переадресовать Вам Ваш же вопрос (раз уж мой не в меру тонкий намек остался непонятым).
Re[2]: С++ culture
От: JURIY  
Дата: 16.11.05 11:56
Оценка: 1 (1) +1 :))
Это всё звучит очень складно и умно — простота, новые принципы кодирования и т.п.
На одной конференции мой коллега задал вопрос проповедникам из Microsoft:
"Как защитить код на шарпе от декомпиляции?"
На что получил ответ:
"Напишите в шестой студии DLL, которая будет хранить в себе весь код, нуждающийся в защите"
И это, повторяю, сказал представитель Microsoft.
Re[4]: С++ culture
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.11.05 18:42
Оценка: :))) :)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Да ведь спорят. Я в свое время мир предложил


PD>http://www.rsdn.ru/Forum/Message.aspx?mid=1445599&amp;only=1
Автор: Pavel Dvorkin
Дата: 20.10.05


PD>Не получается мир.


И прямо во время подписания мирного соглашения из-за острого несогласия с выбранным цветом чернил...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: С++ culture
От: Павел Кузнецов  
Дата: 08.11.05 14:38
Оценка: +4
mrozov,

> Именно так и получается. Массовая распространенность с++ — трагическое недоразумение. Впрочем, насколько я понимаю, это почти чисто российский феномен.


Вы неправильно понимаете. Прикладные "коробочные" продукты в подавляющем большинстве написаны и пишутся на C или C++. Enterprise automation -- да, там много VB, C#, Java. Может, это и изменится в будущем, но пока что это именно так.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[5]: С++ culture
От: Cyberax Марс  
Дата: 08.11.05 16:51
Оценка: +3 :)
mrozov wrote:

> Т.е. Ваша личная высочайшая или даже сверхестественная квалификация ни

> в коей мере не отменяет того простого факта, что большинство
> (подавляющее) людей не способны писать код с той степеню аккуратности,
> которая требуется для грамотного кодирования на с++.

Не нужно сверхвысокой квалификации, просто надо понимать КАК писать
программы на С++. Это совсем несложно, придется выучить:
1. RAII и его использование.
2. Политики владения.
3. Эффективное использование стандартной библиотеки.

Это вполне достаточно, чтобы писать безглючные программы на С++. При
этом не нужно знать про темплейтную магию — я сам долгое время без
проблем программировал на "C с классами", не используя темплейты в своем
коде (но используя "библиотечные").

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[20]: С++ culture
От: mrozov  
Дата: 09.11.05 11:52
Оценка: +1 :)))
E>PS. В следующий раз предлагаю общаться на "ты" -- так проще.

Без проблем. в следующий-то раз мы будем уже старыми знакомыми
Re[12]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.05 01:30
Оценка: :))) :)
Здравствуйте, Kluev, Вы писали:

K>В итоге имеем оверхед на ровном месте. В качестве примера цифры из реальной жизни.

K>В программе ~150000 обьектов в которых 8 фикс.массивов на борту, ~50000 в которых 15.
K>В С++ общее число обьектов: 200 тысяч.
K>В .NETе 150к + 150к*8 + 50к + 50к*15 = 2,150,000

Это из серии:

Назову конкретные цифры: 150, 8, 50, 15, 2150000...



K>Если смысл обсуждать дальше? Конечно можно возразить (на примере того же треугольника) делай вот так и будет щастье:

K>
K>class Triangle
K>{
K>   public Node A, B, C; // вместо массива переменные
K>}
K>

K>Но это уже буллшит какой-то.

Это подобные слова "булшит" какой-то.

Индексированный доступ всего лишь абстракция. Можно реализовать ее так:
using System;
using System.Collections.Generic;
using System.Collections;

class Triangle : ICollection<Node>
{
    public Triangle(Node node1, Node node2, Node node3)
    {
        Node1 = node1;
        Node2 = node2;
        Node3 = node3;
    }

    public Node Node1;
    public Node Node2;
    public Node Node3;

    public IEnumerator<Node> Nodes
    {
        get
        {
            yield return Node1;
            yield return Node2;
            yield return Node3;
        }
    }

    public Node[] ToArray()
    {
        return new Node[] { Node1, Node2, Node3 };
    }

    #region ICollection<Node> Members

    public Node this[int index]
    {
        get
        {
            switch (index)
            {
                case 0:  return Node1;
                case 1:  return Node2;
                case 2:  return Node3;
                default: throw new ArgumentOutOfRangeException("index");
            }
        }
    }

    public bool Contains(Node item)
    {
        return item == Node1 || item == Node2 || item == Node3;
    }

    public void CopyTo(Node[] array, int arrayIndex) { array[0] = Node1; }
    public int Count { get { return 3; } }
    public bool IsReadOnly { get { return true; } }
    public IEnumerator<Node> GetEnumerator() { return Nodes; }
    IEnumerator IEnumerable.GetEnumerator() { return Nodes; }

    public void Add(Node item) { throw new InvalidOperationException(); }
    public void Clear() { throw new InvalidOperationException(); }
    public bool Remove(Node item) { throw new InvalidOperationException(); }

    #endregion
}

struct Node
{
    public Node(double x, double y) { X = x; Y = y; }
    public double X;
    public double Y;

    public static bool operator ==(Node a, Node b)
    {
        return a.X == b.X && a.Y == b.Y;
    }

    public static bool operator !=(Node a, Node b)
    {
        return a.X != b.X || a.Y != b.Y;
    }

    public override bool Equals(object obj)
    {
        if (obj == null || !(obj is Node))
            return false;
        
        return this == (Node)obj;
    }

    public override int GetHashCode()
    {
        return (int)(X * 1000) ^ (int)(Y * 10000);
    }

    public override string ToString()
    {
        return "{ X=" + X + " Y=" + Y + " }";
    }
}

    class Program
    {
        static void Main()
        {
            Triangle triangle1 = new Triangle(new Node(1.123, 2.345),
                new Node(0.123, 0.345), new Node(2.123, 3.345));

            foreach (Node node in triangle1)
                Console.Write(node + " ");

            Console.WriteLine();
            Console.WriteLine();

            Console.WriteLine("triangle1[1]    = " + triangle1[1]);
            Console.WriteLine("triangle1.Node2 = " + triangle1.Node2);
        }
    }


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

K>И это элементарные вещи широко используемыые в повседневной жизни. В NET на таких простых вещах имеешь либо оверхед либо гемморой, а чаще и то и другое вместе взятое.


Ага геморрой. И имя ему инкамсуляция.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.11.05 10:19
Оценка: 39 (3)
Здравствуйте, Шахтер, Вы писали:

E>>Думаю, что вполне возможно. Т.к. assert во время отладки удаляет все обращения по неверному индексу. В релизе, с большой вероятностью, все вызовы инлайнятся, а assert изымается, поэтому лишнего оверхеда нет. А в твоем варианте взятие остатка от деления будет всегда.


Ш>На самом деле на современных процессорах обмен с памятью -- достаточно дорогая операция.


Да. Но и деление никогда не было дешовой операцией. В отличии от сложения или арифметического сдвига.

Ш>Так что что тут будет быстрее без исследования вопроса сказать сложно.


Это точно. Решил посмотреть. Вот чего получилось. Код программы внизу.
capacity: 100000, iterations: 1000
get_via_static_imap duration: 13.75
get_via_local_imap duration: 20.453
get_via_mod duration: 21.203

capacity: 100000, iterations: 100
get_via_static_imap duration: 1.344
get_via_local_imap duration: 2.046
get_via_mod duration: 2.11

capacity: 100, iterations: 100000
get_via_static_imap duration: 1.203
get_via_local_imap duration: 1.907
get_via_mod duration: 1.968

capacity: 1000, iterations: 10000
get_via_static_imap duration: 1.281
get_via_local_imap duration: 1.922
get_via_mod duration: 2.015

capacity: 10000, iterations: 1000
get_via_static_imap duration: 1.187
get_via_local_imap duration: 1.906
get_via_mod duration: 2


Visial C++ 7.1 (-GX -O2).
Intel Pentium M 1.5GHz.

#include <iostream>
#include <string>
#include <vector>
#include <ctime>
#include <cmath>
#include <cstdio>

using namespace std;

class node_t
    {
    private :
        double m_x;
        double m_y;

    public :
        node_t() : m_x( 0 ), m_y( 0 ) {}

        double x() const { return m_x; }
        double y() const { return m_y; }
    };

class triangle_t
    {
    private :
        node_t *    m_nodes[ 3 ];

        static const int imap( int idx )
            {
                static const int m[] = { 1, 2, 0, 1, 2, 0, 1 };
                return m[ idx ];
            }
    public :
        triangle_t( node_t * a, node_t * b, node_t * c )
            {
                m_nodes[ 0 ] = a;
                m_nodes[ 1 ] = b;
                m_nodes[ 2 ] = c;
            }

        const node_t * get_via_static_imap( int idx ) const
            {
                return m_nodes[ imap( idx + 2 ) ];
            }

        const node_t * get_via_local_imap( int idx ) const
            {
                const int m[] = { 1, 2, 0, 1, 2, 0, 1 };
                return m_nodes[ m[ idx + 2 ] ];
            }

        const node_t * get_via_mod( int idx ) const
            {
                return m_nodes[ ( idx + 2 ) % 3 ];
            }
    };

typedef const node_t * (triangle_t:: *pfn_accessor_t)( int idx ) const;

typedef std::vector< node_t > nodes_t;
typedef std::vector< triangle_t > triangles_t;
typedef std::vector< double > results_t;

double
calculate( const triangle_t & t, pfn_accessor_t accessor )
    {
        // Тут какая-то имитация математики.
        return pow( (t.*accessor)( -1 )->x() - (t.*accessor)( 0 )->x(), 2 ) +
            pow( (t.*accessor)( 0 )->x() - (t.*accessor)( 1 )->x(), 2 ) +
            pow( (t.*accessor)( -1 )->y() - (t.*accessor)( 0 )->y(), 2 ) +
            pow( (t.*accessor)( 0 )->y() - (t.*accessor)( 1 )->y(), 2 );
    }

void
meter(
    const std::string & test_case_name,
    const unsigned int iterations,
    const triangles_t & triangles,
    results_t & results,
    pfn_accessor_t accessor )
    {
        std::cout << test_case_name << " " << std::flush;

        std::clock_t start = std::clock();

        for( unsigned int i = 0; i != iterations; ++i )
            {
                for( unsigned int j = 0, j_max = triangles.size();
                        j != j_max; ++j )
                    results[ j ] = calculate( triangles[ j ], accessor );
            }

        std::clock_t finish = std::clock();

        std::cout << "duration: "
                << double( finish - start ) / CLOCKS_PER_SEC
                << std::endl;
    }

void
determine_capacities( int argc, char ** argv,
    unsigned int & capacity,
    unsigned int & iterations )
    {
        const unsigned int default_capacity = 100000;
        const unsigned int default_iterations = 1000;

        capacity = default_capacity;
        iterations = default_iterations;

        if( 3 == argc )
            {
                unsigned int t1, t2;
                if( 1 == sscanf( argv[ 1 ], "%u", &t1 ) &&
                        1 == sscanf( argv[ 2 ], "%u", &t2 ) )
                    {
                        capacity = t1;
                        iterations = t2;
                    }
                else
                    std::cerr << "arguments (" << argv[ 1 ]
                            << ", " << argv[ 2 ] << ") ignored" << std::endl;
            }

        std::cout << "capacity: " << capacity << ", iterations: "
                << iterations << std::endl;
    }

int main( int argc, char ** argv ) 
    { 
        unsigned int capacity;
        unsigned int iterations;
        determine_capacities( argc, argv, capacity, iterations );

        nodes_t nodes( capacity * 3 );
        triangles_t triangles;
        triangles.reserve( capacity );

        results_t results( capacity );

        for( unsigned int i = 0; i != capacity; ++i )
            triangles.push_back(
                    triangle_t(
                            &nodes[ i * 3 ],
                            &nodes[ i * 3 + 1 ],
                            &nodes[ i * 3 + 2 ] ) );

        meter( "get_via_static_imap", iterations, triangles, results,
                &triangle_t::get_via_static_imap );

        meter( "get_via_local_imap", iterations, triangles, results,
                &triangle_t::get_via_local_imap );

        meter( "get_via_mod", iterations, triangles, results,
                &triangle_t::get_via_mod );
    }
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: С++ culture
От: mrozov  
Дата: 16.11.05 17:11
Оценка: 24 (1) +1 :)
Все так. Или почти так.

Просто если принять как данность, что кодирование на голом с++ — вещь неправильная, то следующий логичный шаг — использовать язык/среду, в которой соответствующие проблемы были устранены изначально.

Раньше особого выбора просто не было. Теперь есть.
Re[22]: С++ culture
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.12.05 18:26
Оценка: 16 (1) +2
VladD2 wrote:
>
> В общем-то после этоих слов уже дальше говорить не о чем. Наличие HAL-а
> как раз и говорит о ориентации ОС на минкроядерную архитектуру.
> Собственно зачем монолитной ОС HAL если любой драйвер может залезть в
> любой аспект железки? Единственное с чем можно согласиться, в последнее
> время в погоне за производительностью многие ОС инзначально
> ориентировавшиеся на микроядерную архитектуру начали постепенно нарушать
> принцыпы которые декларировались ими в начале. NT4 хороший тому пример.
> Ради быстрой 3D-графики по сути драва видеокарт были всунуты в ядро и
> стали лезть к железу напрямую. И это при том, что во многих случаях эта
> самая 3D-графика вообще не нужна.

NT никогда не была микроядерной ОС. Ядро НТ монолитно, работает в едином
адресном пространстве. Наличие динамической загрузки драйверов никак не
отменяет этого факта (иначе придется признать, что любой современный
UNIX тоже имеет микроядерную архитектуру, что неправда).

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

> V> Ибо в микроядерной архитектуре общение с драйверами происходит

> наиболее затратно,
>
> Во как? Кто тебе это сказал? Ты приписываешь микроядерной архитектуре
> проблемы современнх ОС и современных процессоров. В них процессы
> защищаются друг от друга аппоратно и имеются большие накладные расходы
> на комуникацию между процессами. Между тем в безопасной ОС без проблем
> можно сделать легкие процессы взаимодействующие в рамках одного
> адресного пространтсва. При этом снимаются ограничения скорости и идеи
> микрояденой архитектуры становятся очень даже приемлемыми.

Кеши у процессоров работают не слишком эффективно при постоянном
переключении адресного пространства. Причем если на x86 это не очень
заметно (там кеш работает с физическими адресами), то на многих RISC'ах
переключение контекстов стоит очень дорого именно из-за необходимости
проинвалидировать весь кеш (да еще и слить его в память, если кеш с
отложенной записью).

> V> т.е. наличие лишнего драйвера дорогого стоит.

>
> Еще раз. Последий. Если я правильно понял суть исследования, то ребята
> делают максимально надежную ОС. В ней принципиально предпочитаются более
> надежные решения более быстрым. О скорости они конечно тоже думают, но
> уже во вторую очередь. Все драйверы в этой ос являются отдельными
> процессами. Никакой экономии драйверов не делается. Все процессы
> общаются между собой исключительно по средствам типизированных
> сообщений. Ну, а приемлемая скорость достигается тем, что процессы живут
> в одном адресном пространстве, а их память защищается применением
> типобезопасного языка и верификации кода.

Ух, я этого не знал. Т.е., MS-DOS (Windows 3.1), но с защитой при
компиляции. Прекрасная ОС, ничего не скажешь...
Posted via RSDN NNTP Server 2.0
Re[14]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.11.05 13:49
Оценка: 12 (1) +1 -1
Здравствуйте, sch, Вы писали:

sch>Тут просто действует общее правило, которое заключается в том, что на C++ можно делать *все*, только напильником поработать надо


На ассемблере можно сделать еще больше. Вот толку от того — 0.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: С++ culture
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.11.05 11:30
Оценка: 9 (1) +2
Здравствуйте, Kluev, Вы писали:

K>Дотнетовский массив — это ссылочный тип который в GC-хипе аллоцируется. В NET нельзя сделать массив частью аггрегата, как в С++:


struct CSharpTriangle
{
  public fixed Node nodes[3];
}
... << RSDN@Home 1.2.0 alpha rev. 617>>
AVK Blog
Re[23]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.11.05 12:32
Оценка: 3 (2) :)
Здравствуйте, Шахтер, Вы писали:

Ш>Здравствуйте, eao197, Вы писали:


Ш>Глянь ещё ассемблер -- очень познавательно.


На ассемблере мне со времени окончания универа не приходилось программировать, так что в ассемблерном коде я вообще слабо чего понял

Самое смешное, что когда я привел Владу код (Re[17]: С++ culture
Автор: eao197
Дата: 10.11.05
), то я совершенно не думал о производительности. Просто написал метод Triangle::node_at(), решил, что это не дело -- нужно еще и константный вариант для симметрии сделать. Начал делать Triangle::node_at() const -- оказалось, что imap дублируется. Сразу же сделал рефакторинг, получилась схема со статическим методом imap. В общем, старался написать красивый код, а он, зараза, еще и быстрым получился. А еще говорят, что красота -- это субъективное понятие :))
Автор: Дарней
Дата: 10.11.05
.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[21]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.12.05 16:36
Оценка: 3 (1) -1 :)
Здравствуйте, vdimas, Вы писали:

V>Твое мнение насчет "научность vs инженерность" разработки понятна. Если они предоставят какие-то новые парадигмы и подходы мировому сообществу, то может быть ты прав. А если эта разработка будет закрытым образом использована MS, т.е. использована напрямую в практических целях, то согласно твоему же определению, это будет просто макетирование очередной инженерной разработки.


Ну, и почему ты считашь, что имешь право определять степень научности чужих работ "по запаху"? Люди называют свою работу научным исследованием. И до тех пор пока нет не будет точно доказано, что они занимаются профанацией не стоит ставить под сомнение их честность и компетентность.

V>И насчет инноваций — неплохо тебе ознакомится с JavaMe, и конкретно с устройствами, типа @Blackberry. Тогда мы сможем поговорить о степени инноваций.


А зачем ты пыташся перевести разговор в плоскость сталкивания лбами разных разрботок. Чем бы не являлась JavaMe — это не сколько не мешает производить аналогичные или другие исследования другим людям.

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

V>Я вот только одного не понимаю, почему когда я пытаюсь развить тему привязки HAL к железу и уровне его абстракции, ты отсылаешь меня к микроядерной архитектуре???


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

V> Еще при этом пытаешься выставить за ламера.


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

V> Я реально имел дело с совершенно различными по уровню HAL, и знаю о чем говорю. Понятие HAL никак не пересекается с архитектурой ОС.


В общем-то после этоих слов уже дальше говорить не о чем. Наличие HAL-а как раз и говорит о ориентации ОС на минкроядерную архитектуру. Собственно зачем монолитной ОС HAL если любой драйвер может залезть в любой аспект железки? Единственное с чем можно согласиться, в последнее время в погоне за производительностью многие ОС инзначально ориентировавшиеся на микроядерную архитектуру начали постепенно нарушать принцыпы которые декларировались ими в начале. NT4 хороший тому пример. Ради быстрой 3D-графики по сути драва видеокарт были всунуты в ядро и стали лезть к железу напрямую. И это при том, что во многих случаях эта самая 3D-графика вообще не нужна.

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


С чего бы это? Наоборот требуется минимальное ядро абстрагирующее от самых тонких вещей. Далее дрова работая через это микроядро абстрагируют ОС от остальных деталей реализации железа.

V> Ибо в микроядерной архитектуре общение с драйверами происходит наиболее затратно,


Во как? Кто тебе это сказал? Ты приписываешь микроядерной архитектуре проблемы современнх ОС и современных процессоров. В них процессы защищаются друг от друга аппоратно и имеются большие накладные расходы на комуникацию между процессами. Между тем в безопасной ОС без проблем можно сделать легкие процессы взаимодействующие в рамках одного адресного пространтсва. При этом снимаются ограничения скорости и идеи микрояденой архитектуры становятся очень даже приемлемыми.

V> т.е. наличие лишнего драйвера дорогого стоит.


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

V>Именно поэтому я и считаю, что для каждой новой железки для этой Сингулярити придется приличную часть НЕПЕРЕНОСИМОГО кода по-любому писать в unmanaged.


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

V>Тут я кое-что ответил Синклеру, не хочу повторяться http://www.rsdn.ru/Forum/Message.aspx?mid=1494189&amp;only=1
Автор: vdimas
Дата: 18.11.05


Там ровным счетом ни одного аргумента. Одни домыслы.

V>----------

V>И по поводу моего незнания C#. А-я-яй опять дергать из контекста. Я говорил про прямой доступ не только к памяти, но и к портам и прерывания. Работа с прерываниями — это задание своих точек входа на обработчики. Я спрашивал — возможно ВСЕ это? НЕТ. На C# вряд ли можно написать корректную точку входа для обработки прерывания для конкретного проца. Т.е. в ф-ии HAL помимо всего того, что прочтешь по ссылке выше, надо будет добавлять нечто вроде SetStaticMethodAsIRQEntry, это тянет за собой еще одну проблему — надо обеспечить, чтобы указанный метод был явно загружен джитом, ибо обработка прерываний по сути должна иметь быструю реакцию, а не ждать, пока джит что-то там разджитит,

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

V>т.е. в API надо добавлять еще методы по явному управлению VM (пусть даже во внутренние API OС).


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

V>В общем, когда они дойдут до более-меннее реальной системы и откроют всю информацию по ней, тогда можно будет судить, что именно и где managed, а где нет.


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

V>Простое заявление "у нас драйвера на C#" говорит слишком мало.


Но куда больше чем все твои рассуждения вместе взятые.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: С++ culture
От: Kluev  
Дата: 09.11.05 09:27
Оценка: 1 (1) -1 :)
Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Kluev, Вы писали:


K>>Для примера достаточно одной таблетки — простой класс треугольник:

K>>
K>>class CSharpTriangle
K>>{
K>>  public Node[] nodes = new Node[3]; // все приехали, можете закрывать свою лавочку
K>>}
K>>


GZ>Я сам могу привести кучу аргументов против Net в CAD системах, но Холмс, почему нужно закрывать лавочку именно здесь?


Дотнетовский массив — это ссылочный тип который в GC-хипе аллоцируется. В NET нельзя сделать массив частью аггрегата, как в С++:
struct Triangle
{
   Node  *nodes[3];
};

В итоге имеем оверхед на ровном месте. В качестве примера цифры из реальной жизни.
В программе ~150000 обьектов в которых 8 фикс.массивов на борту, ~50000 в которых 15.
В С++ общее число обьектов: 200 тысяч.
В .NETе 150к + 150к*8 + 50к + 50к*15 = 2,150,000
Если смысл обсуждать дальше? Конечно можно возразить (на примере того же треугольника) делай вот так и будет щастье:
class Triangle
{
   public Node A, B, C; // вместо массива переменные
}

Но это уже буллшит какой-то.
В треугольнике, например, нужен именно массив, который для удобства еще и закольцовывается:
Node* node_at( int idx )
{
   static const int imap[] = { 1, 2, 0, 1, 2, 0, 1 };
   return nodes[imap[idx+2]]; // транслируем колецевой индекс в обычный
}
// юзается очень удобно, пример вычисление всех углов:
void angles(Triangle &t)
{
   double angs[3];
   for ( int i = 0; i < 3; i++ )
      angs[i] = angle( t.node_at(i-1), t.node_at(i), t.node_at(i+1) );
    
}


И это элементарные вещи широко используемыые в повседневной жизни. В NET на таких простых вещах имеешь либо оверхед либо гемморой, а чаще и то и другое вместе взятое.
Re[16]: С++ culture
От: Павел Кузнецов  
Дата: 10.11.05 16:07
Оценка: 1 (1) +2
VladD2,

> КДВ>Исследования, на то они и исследования, чтобы ошибаться.

>
> Исследования делаются, чтобы проверить свои суждения, а не чтобы ошибаться.

Твой оппонент хотел сказать, что при проверке суждения часто оказываются ошибочными. Соответственно, само по себе наличие исследований ни о чем, кроме интереса к теме, не говорит.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re: С++ culture
От: aik Австралия  
Дата: 19.10.05 14:15
Оценка: :)))
Здравствуйте, Ligen, Вы писали:

L>Как следствие — спрос на С++ программистов возрастает неимоверно.

L>По С++ реально не хватает спецов. Часто девелопером может устроится человек с минимальным опытом — 5 лет назад такое казалось невозможным.
L>У меня лично за прошлую неделю было n обращений в аську(!) с предложениями сменить работу.

Это где так удачно аську разместил? Можно в мыло
Re[5]: С++ culture
От: sch  
Дата: 20.10.05 09:23
Оценка: +2 -1
> Это-то фигня. Больше всего раздражает, что GC уничтожает память
> недетерминировано. А значит RAII и подобные идиомы не проходят.

Ну и?
Я не люблю играть в футбол, потому что правила запрещают играть руками
Плох ли футбол или я не понимаю причины, по которым правила фубола такие, какие они есть?
Posted via RSDN NNTP Server 1.9
Re[3]: С++ culture
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 03.11.05 01:00
Оценка: +2 :)
DG>>более высокая стоимость в C++ ошибок других

VD>А свои что бесплатные? Или все кто пишут на С++ сразу автоматом получают манию величия в форме веры в свою непогрешимость?


Свое бревно — глаз не колет.
Re[5]: С++ culture
От: Шахтер Интернет  
Дата: 07.11.05 09:09
Оценка: :)))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Да ведь спорят. Я в свое время мир предложил


PD>>http://www.rsdn.ru/Forum/Message.aspx?mid=1445599&amp;only=1
Автор: Pavel Dvorkin
Дата: 20.10.05


PD>>Не получается мир.


ГВ>И прямо во время подписания мирного соглашения из-за острого несогласия с выбранным цветом чернил...


Ну что делать, если у C++ ников кровь голубая...
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[9]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.11.05 13:49
Оценка: -3
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Тогда я прекращаю дискуссию.


Об этом можно и не сообщать.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: С++ culture
От: Kluev  
Дата: 08.11.05 13:01
Оценка: +1 -2
Здравствуйте, mrozov, Вы писали:

M>Да нет же, все не так. Нужно писать на .Net, потому, что C++ глючный, т.к. я, все мои знакомые программисты и подавляющее большинство других программистов, на нем пишут с ошибками. А количество ошибок на .net заметно меньше, как и общая скорость разработки. И практика моей компании показывает, что стоимость решений на с++ оказывается неприемлимо высокой.


Есть такая отрасль CAD/CAE/CAM называется. Дык вот, net и java там не жильцы и это так же очевидно как 2х2=4. В качестве примера некоторые сведения о реальной САЕ. Исходные данные ок 30 мб, результат расчета от 1-4Гб, расчетный модуль разделен на три процесса, т.к. адрессного пространства в 2Гб на процесс не хватает чтобы втиснуть все. Работа с памятью написана ручками (свой менеджер кучи), т.к. стандартный crt-шный дохнет на таких обьемах (из-за сильной фрагментации памяти). Юзать дотнет и жабу в качестве основных инструментов разработки здесь абсолютно бесмысленно т.к. даже на рынок не сможешь войти. Более того они и по удобству здесь не годятся, C++ самое то, аналогов по удобству и быстродействию даже и близко нет.

M>Короче — если мыслить с позиции человека, который отвечает за разработку, то выбор очевиден. C++ только там, где этого нельзя избежать.

M>Из любого правила есть исключения, но общая тенденция такова.

Только исключений слишком много. Фактически весь back-end на С/С++ написан и альтернатив нет. Там где есть куча готовых компонентов (внутренне как правило написанных на С/С++) и можно заюзать стандартный большой фреймворк — удобно. Но много ли таких задач? На самом деле имхо нет. А где есть свой core-development там уже бесполезняк. Не так же и по тому, что в таких языка просто подходящих средств нет. Для примера достаточно одной таблетки — простой класс треугольник:
class CSharpTriangle
{
  public Node[] nodes = new Node[3]; // все приехали, можете закрывать свою лавочку
}


M>А вообще, у меня есть друг, в чем-то похожий (видимо) на Вас. Только он не сишник, он уже много лет на скриптовых языках пишет. Очень грамотный и очень одаренный товарищ, золотые руки.

M>Вот ему .net не нужен. И с++ ему тоже не нужен. И от строгой типизации он видит один вред.

Все справедливо, ему не нужен С++, а многим софтовым фирмам не нужен он.
Re[20]: С++ culture
От: Шахтер Интернет  
Дата: 11.11.05 08:47
Оценка: +3
Здравствуйте, eao197, Вы писали:

E>Здравствуйте, DarkGray, Вы писали:


E>>>А еще более вероятно, что в реальной системе что-то вроде:


DG>>И это все шаманство будет быстрее, чем:

DG>>return nodes[(idx+2)%3];

E>Думаю, что вполне возможно. Т.к. assert во время отладки удаляет все обращения по неверному индексу. В релизе, с большой вероятностью, все вызовы инлайнятся, а assert изымается, поэтому лишнего оверхеда нет. А в твоем варианте взятие остатка от деления будет всегда.


На самом деле на современных процессорах обмен с памятью -- достаточно дорогая операция.
Так что что тут будет быстрее без исследования вопроса сказать сложно.
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[4]: С++ culture
От: kliff Россия http://www.esignal.ru
Дата: 16.11.05 08:01
Оценка: :)))
Здравствуйте, sch, Вы писали:

sch>Соответственно, больше всего пугает самое новое и необычное: например, чаще всего у C++ программистов нарекания вызывает GC из .NET. Боже мой, он будет лазить по моим структурам когда ему захочется, и будет освобождать память!

sch>Сам!


Бр. Аж мороз по коже
Re[6]: С++ culture
От: Kubera Россия  
Дата: 11.01.06 14:47
Оценка: +1 :))
Здравствуйте, eao197, Вы писали:

E>Геннадий, ты пропустил нашу драку с Владом по этому поводу Re[18]: Следующий язык программирования
Автор: eao197
Дата: 08.10.05


Нет, это ты упустил "драки" ГВ vs AndrewVK+Vlad2+IT, проходившие года эдак три назад. Удивительно, но оказывается, люди ещё не досказали что-то друг друг...
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Re[2]: С++ culture
От: mrozov  
Дата: 08.11.05 08:09
Оценка: 48 (1) +1
Я бы все-таки сказал — "низкая квалификация с++ кадров".

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

Даст бог — через какое-то время ситуация изменится и останутся только действительно грамотные люди. Но до тех пор, пока отдельные товарищи гонят волну истерии и призывают писать на с++ прикладные проекты как правило, этого ждать не приходится.
Re[22]: С++ culture
От: Шахтер Интернет  
Дата: 11.11.05 11:33
Оценка: 38 (2)
Здравствуйте, eao197, Вы писали:

Глянь ещё ассемблер -- очень познавательно.


?get_via_static_imap@triangle_t@@QBEPBVnode_t@@H@Z PROC NEAR ; triangle_t::get_via_static_imap, COMDAT
; _this$ = ecx

; 45   :                 return m_nodes[ imap( idx + 2 ) ];

    mov    eax, DWORD PTR _idx$[esp-4]
    mov    edx, DWORD PTR ?m@?1??imap@triangle_t@@CAHH@Z@4QBHB[eax*4+8]
    mov    eax, DWORD PTR [ecx+edx*4]

; 46   :             }

    ret    4
?get_via_static_imap@triangle_t@@QBEPBVnode_t@@H@Z ENDP    ; triangle_t::get_via_static_imap


?get_via_local_imap@triangle_t@@QBEPBVnode_t@@H@Z PROC NEAR ; triangle_t::get_via_local_imap, COMDAT
; _this$ = ecx

; 49   :             {

    sub    esp, 28                    ; 0000001cH

; 50   :                 const int m[] = { 1, 2, 0, 1, 2, 0, 1 };

    mov    eax, 1
    mov    DWORD PTR _m$[esp+28], eax
    xor    edx, edx
    mov    DWORD PTR _m$[esp+40], eax
    mov    DWORD PTR _m$[esp+52], eax

; 51   :                 return m_nodes[ m[ idx + 2 ] ];

    mov    eax, DWORD PTR _idx$[esp+24]
    mov    DWORD PTR _m$[esp+32], 2
    mov    DWORD PTR _m$[esp+36], edx
    mov    DWORD PTR _m$[esp+44], 2
    mov    DWORD PTR _m$[esp+48], edx
    mov    edx, DWORD PTR _m$[esp+eax*4+36]
    mov    eax, DWORD PTR [ecx+edx*4]

; 52   :             }

    add    esp, 28                    ; 0000001cH
    ret    4
?get_via_local_imap@triangle_t@@QBEPBVnode_t@@H@Z ENDP    ; triangle_t::get_via_local_imap


?get_via_mod@triangle_t@@QBEPBVnode_t@@H@Z PROC NEAR    ; triangle_t::get_via_mod, COMDAT
; _this$ = ecx

; 56   :                 return m_nodes[ ( idx + 2 ) % 3 ];

    mov    eax, DWORD PTR _idx$[esp-4]
    add    eax, 2
    push    esi
    cdq
    mov    esi, 3
    idiv    esi
    pop    esi
    mov    eax, DWORD PTR [ecx+edx*4]

; 57   :             }

    ret    4
?get_via_mod@triangle_t@@QBEPBVnode_t@@H@Z ENDP        ; triangle_t::get_via_mod



У меня получается

15.3
21.5
27.3

А вот Intel заменяет деление умножением.


?get_via_mod@triangle_t@@QBEPBVnode_t@@H@Z    PROC NEAR
; parameter 1(this): ecx
; parameter 2(idx): 8 + esp
$B48$1:                         ; Preds $B48$0
$LN1255:
        push      edi                                           ;55.13
        mov       edi, ecx                                      ;55.13
$LN1256:
        mov       eax, DWORD PTR [esp+8]                        ;54.24
$LN1257:
        lea       ecx, DWORD PTR [eax+2]                        ;56.41
$LN1258:
        mov       eax, 1431655766                               ;56.47
        imul      ecx                                           ;56.47
        mov       eax, ecx                                      ;56.47
        sar       eax, 31                                       ;56.47
        sub       edx, eax                                      ;56.47
        lea       eax, DWORD PTR [edx+edx]                      ;56.47
        add       eax, edx                                      ;56.47
        sub       ecx, eax                                      ;56.47
$LN1259:
        mov       eax, DWORD PTR [edi+ecx*4]                    ;56.24
        pop       edi                                           ;56.24
        ret       4                                             ;56.24
        ALIGN     4
                                ; LOE
; mark_end;
?get_via_mod@triangle_t@@QBEPBVnode_t@@H@Z ENDP


И получается побыстрее.

14.9
23.6
18.6
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[14]: С++ culture
От: GlebZ Россия  
Дата: 18.11.05 17:59
Оценка: 30 (2)
Здравствуйте, vdimas, Вы писали:

V>Джаву не люблю, но разнообразию и качеству инструментов должен отдать должное. Взять тот же Эклипс с его бесплатными сотнями прибамбасов от UML до поддержки высокоуровневых вещей, типа struts и spring. Ты наверно не обратил внимание на эти 2 названия, а они весьма сильнозвучащие. Это такие технологии лепки сложных систем на-лету. Мизинцем левой ноги. На .Net все еще предстоит трахаться ручками и самостоятельно и довольно-таки много, ибо, кроме платформы практически ничего больше нет.

Ты не обращал внимание на такое?
struts vs ASP.NET
Spring.NET

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: С++ culture
От: GU Glez  
Дата: 03.11.05 15:43
Оценка: 6 (2)
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>И хотя я могу показаться крамольным... Тем не менее, следует учитывать, что язык в немалой степени определяет способ мышления. Хотя, если задача, или ещё какие-либо условия мышления не требуют, то спору нет, в таком контексте бессмысленно говорить о различиях языков, API и прочих подобных вещей.


VD>Язык определяет сужение мышления. Люди знающий один ЯП принципиально не могут мыслить широко. А вот когда ты знашь много разных языков, то на любом языке ты можешь мысль более свободно.


Вообще-то, это говорил Достоевский и об этом говорят многие ученые. Но это так к сведению. Меня всегда удивляет одно — где можно найти профессионального врача владеющего всеми (или очень многими) областями медицины? Не помню кто сказал, но думаю это рядом с истиной: "Профессионал во всем — зовется дилетант". Хотя, с утверждением, что программирование — область в которой необходимо постоянно изучать и "мыслить как можно лучше", путем изучения нового — думаю согласятся многие.
С уважением,
GU Glez [Джи Ю Глиз]
Re: С++ culture
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 22.10.05 08:44
Оценка: 1 (1) +1
L>Как следствие — спрос на С++ программистов возрастает неимоверно.
L>По С++ реально не хватает спецов. Часто девелопером может устроится человек с минимальным опытом — 5 лет назад такое казалось невозможным.
L>У меня лично за прошлую неделю было n обращений в аську(!) с предложениями сменить работу.
L>Опять таки, у С++ сообщества появляется оттенок элитизма, любезно упомянутый комрадами в ветке писал на с++
Автор: VladD2
Дата: 18.10.05


Все зависит от того — кем ты хочешь быть и дальше.

если хочешь быть и дальше рядовым спецом, то все отлично и правильно.

Но если хочеться вести проекты, то проблемы:
дороговизна С++-кадров
нехватка C++-кадров
более высокая стоимость в C++ ошибок других
и т.д.
встанут и перед тобой тоже.
Re[11]: С++ culture
От: vdimas Россия  
Дата: 18.11.05 13:03
Оценка: 1 (1) +1
Здравствуйте, mrozov, Вы писали:

M>В целом согласен. И о согласии с этой точкой зрения неоднократно заявлял выше, уважаемые товарищи с лопатами.

M>Но! Осмелюсь утверждать, что не "посмотрим через годик", а "посмотрели год назад".

Да вот фиг там — год назад. С ORM ситуация все еще неясная, стандартов нет, полный хаос. В серверной и вообще высокоуровневой архитектуре АБСОЛЮТНО НИКАКИХ наработок. Каждый изголяется как может. Сравни с тем же Struts или Spring в Java. Наличие стандартов у них подталкивает разработку все более и более удобного инструментария для высокоуровневого макетирования/реализации приложений (эти стадии на том высоком уровне управляемости уже мало различимы, как тебе?).

Далее.
Из тулзов UML<->код ни одного более-менее адекватного халявного. RationalXDE и PD11 стоят просто каких-то заоблачных денег. Бесплатного дизайнера отчетов и вообще нормального опен-сорс ReportDesigner+engine — нет. Есть недорогой SharpShooter, но у него бока и глюки при подстановке своих компонентов (Chart от Infragistics, например). Есть еще от DevExpress — но какой-то бледненький редактор отчетов в нем, я бы не рискнул поставлять систему, где требуется Run-time ReportDesigning в production с ним.

Ах-ах-ах — Resharper... Блин, 2001-й год, IDEA. Здрасьььте, внезапно обнаружили, что в язаках типа C# оказывается можно точно определить множество вариантов подстановок в каждом конкретном случае.. приплыли. Вернее, разработчики все теже, просто это мы только проснулись.

Я смотрю на ситуацию для дотнета — ну вот просто нихрена нет, кроме "фреймворка" и каких-то слабосвязанных полу-поделок со стороны.

Дотнет (пока) еще не показал своего потенциала. По количеству и качеству околодотнетного инструментария мы еще барахтаемся на уровне Java примерно 2000-го года. Правда, довольно быстро набирает сторонников и общий "вес" всех "поделок". Но, насчет годика — это я прогнал. Как минимум года 3 надо еще посмотреть, там видно будет.


--------
Мы сами используем на одной из составных частей нашей системы C#. И пол-года назад я прошерстил весь интернет на предмет наличия готовых нормальных высокоуровневых фреймворков (а что, раз уж принято решение использовать C#, дык его надо выдоить до последней капли), ан нет... Как я уже высказался — куча слабосвязанных поделок, многие из которых претендуют максимум на слабоотработанный макет. Поэтому приличную часть енжина в своей системе делали ручками. Спасибо IT за удачную реализацию маппинга.
Re[3]: С++ culture
От: aik Австралия  
Дата: 19.10.05 16:48
Оценка: +2
Здравствуйте, Павел Кузнецов, Вы писали:

>> А я вот честно говоря не понимаю причин, по которым спорят о преимуществах одних языков над другими языками, одних API над другими API, одних компиляторов над другими компиялторами. По моему скромному мнению, профессионал может работать с любыми языками, средставами, API, девкитами и прочим; все что нужно, для того, чтобы быть производительным -- компьютер, тишина и немного кофе.

ПК>Будет ли один и тот же человек одинаково производительным, пользуясь разными инструментами?

минимум 2 недели — нет. Дальше зависит от соображалки и насколько изменилось окружение вообще, а не только инструмент.
Re[8]: С++ culture
От: Cyberax Марс  
Дата: 20.10.05 11:08
Оценка: +2
Kisloid wrote:

> C>И ну. Достает писать try..finally/using блоки в C#/Java, а в С++ я про

> C>них уже забыл.
> Кстати мня тоже это не радует, интересно, а почему бы просто не
> добавить плюс к управляемому хипу еще и неуправляемый ??? В таком
> случае я уже давно бы про С++ забыл бы...

Welcome to C++/CLI

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 2.0 beta
Sapienti sat!
Re[8]: С++ culture
От: Cyberax Марс  
Дата: 03.11.05 08:37
Оценка: +2
VladD2 wrote:

> C>И ну. Достает писать try..finally/using блоки в C#/Java, а в С++ я про

> C>них уже забыл.
> Можно по подробнее о проблемах с написанием using-га?

0. Его можно забыть.
1. using для ресурсов, хранящихся в полях класса уже не поможет.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[5]: С++ culture
От: Глеб Алексеев  
Дата: 03.11.05 16:20
Оценка: +2
Здравствуйте, GU Glez, Вы писали:

VD>>Язык определяет сужение мышления. Люди знающий один ЯП принципиально не могут мыслить широко. А вот когда ты знашь много разных языков, то на любом языке ты можешь мысль более свободно.


GG>Вообще-то, это говорил Достоевский и об этом говорят многие ученые. Но это так к сведению. Меня всегда удивляет одно — где можно найти профессионального врача владеющего всеми (или очень многими) областями медицины? Не помню кто сказал, но думаю это рядом с истиной: "Профессионал во всем — зовется дилетант". Хотя, с утверждением, что программирование — область в которой необходимо постоянно изучать и "мыслить как можно лучше", путем изучения нового — думаю согласятся многие.


Да, и Людвиг Виттгенштейн говорил о том же (он к нашим баранам поближе Достоевского будет) — "границы моего языка есть границы моего мира".

Замечания насчет специализации, дилетантов и аналогия с врачами — хорошие, но упускают один момент. Естественно, сейчас существует масса технологий, операционных систем, платформ, библиотек, API для решения различных задач, и здесь без специализации никуда. Но сложность ПО — везде одна, инструментов абстракции и современнных методов борьбы со сложностью ПО — не так-то много, поэтому ориентироваться в них, ИМХО, стоит, независимо от специализации.
Т.к. в основной работе программист скорее всего использует компилируемый статически типизированный ОО-язык и имеет представление о предке ОО — структурном программировании, то для эрудиции не вредно ознакомиться просто с парой представителей языков с другими парадигмами — интерпретируемые, динамически типизируемые, функциональные, логические, с выводом типов, ленивые, их не так много наберется.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: С++ culture
От: GU Glez  
Дата: 04.11.05 22:38
Оценка: -2
Здравствуйте, AndrewVK, Вы писали:

AVK>Впрочем неважно. Главное что в мед. училище все студенты изучают и фармакологию, и хирургию, и патологоанатомию и много чего еще. А вот некоторые программисты почему то считают что знания одного C++/Delphi/C# etc достаточно для того чтобы считать себя высококлассными спецами. Пример — Основы. Что это?
Автор: kilonet2
Дата: 29.10.05
.

Правильно. Но и мы — тех. специалисты — на факультетах изучаем историю, философию, социологию и т.д. и т.п. Еще многое что изучаем по смежным специальностям. Но ведь делаем мы это не все время, а то работать будет некогда Изучается только нужное. Чувствую, что AndrewVK раздвинул таки рамки темы
На самом деле, тут не надо забывать частное отношение к программированию. Т.е. есть те кто относится как к искусству, другие как к ремеслу — еще и от этого много споров, ИМХО. Просто опыт говорит о том, что человек с хорошим мат/лог/аналит. мышлением и относящийся к программированию как ремеслу, действительно не чувствует разницы на чем писать. Это плюс
... Но это будет до поры до времени. Когда эта пора придет (обычно — время оптимизации о подчищения, выяснения причины "ну что еще тебе надо?"), данный человек уже не сможет просто применить аналитическое мышление и начнет копать, лазить вообщем сделает как-нибудь, но не совсем как нужно. Потому что "как нужно" приходит с опытом. А от куда ему взяться, если человек тратил время на изучение нового языка, новых технологий не особо вдаваясь в их тонкости — на это нет времени и вообще считается mauvais tonne. Это минус.
Одно дело — знание языков, и совсем другое — знание технологий. Мастер ведь на то и мастер — чтобы знать о своем ремесле почти все. А язык, действительно, средство выражения своих мыслей. ИМХО, т.к. человек мыслит по большей части образами, то в этом-то и вся загвоздка — ведь успешно решив какую-то задачу на одном языке уже труднее будет перенести это же решение на другой язык вот так сходу, т.к. в нашей памяти даже стиль/средство написания/выражения мысли играет такую же роль как и сам контекст выражения.
С уважением,
GU Glez [Джи Ю Глиз]
Re[11]: С++ culture
От: sch  
Дата: 07.11.05 11:22
Оценка: -1 :)
E>Единственное проявление динамизма Java, которое приходит мне в голову -- это возможность вызова либого метода объекта через reflection с передачей аргументов в виде object[]. Только, имхо, маловато этого, чтобы динамическим языком называться. Поэтому, как мне кажется, динамизм некоторых языков сильно преувеличивается.

Сделать на C++ библиотеку, которая будет реализовывать нечто подобное довольно просто. Опять же, при грамотном использовании шаблонов, C++ может дать гораздо более разнообразную динамичность, чем другие языки.
Re[12]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.11.05 12:47
Оценка: +2
Здравствуйте, sch, Вы писали:

E>>Единственное проявление динамизма Java, которое приходит мне в голову -- это возможность вызова либого метода объекта через reflection с передачей аргументов в виде object[]. Только, имхо, маловато этого, чтобы динамическим языком называться. Поэтому, как мне кажется, динамизм некоторых языков сильно преувеличивается.


sch>Сделать на C++ библиотеку, которая будет реализовывать нечто подобное довольно просто.


Ануткать

Принципиальная разница будет в том, что в Java можно в run-time собрать необходимое количество аргументов в object[] и вызвать любой метод по его имени. В С++ подобный вызов можно будет сделать только для тех, методов, к которым шаблонные обертки были приделаны.

sch> Опять же, при грамотном использовании шаблонов, C++ может дать гораздо более разнообразную динамичность, чем другие языки.


Ключевые слова: "грамотном использовании" и "может дать". Слишком сильные "если" А в уже готовых динамических языках динамичность можно использовать прямо здесь и прямо сейчас. Пример, как водится, из Ruby:
# Обертка вокруг теста для того, чтобы не вылетать по исключению.
def execute_test_case( message )
    begin
        puts "-- #{message} --"
        yield
    rescue Exception => x
        puts "!!! caught: #{x} !!!"
    end
end

# Исходный класс и его методы.
class Test
    def hello; puts "hello"; end
    def bye; puts "bye"; end
end

# Тестируемый объект. Важно отметить, что все последующие модификации
# класса Test будут отражаться на уже существующем объекте.
t = Test.new

execute_test_case "Original Test class" do t.hello; t.bye end

# Теперь метод bye нам не нужен.
class Test
    remove_method :bye
end

execute_test_case "Test class without bye method" do t.hello; t.bye end

# Теперь заменяем метод hello и возвращаем метод bye
class Test
    def hello; puts "Hello, world"; end
    def bye; puts "Bye, world"; end
end

execute_test_case "Modified Test class" do t.hello; t.bye end


Получаем:
-- Original Test class --
hello
bye
-- Test class without bye method --
hello
!!! caught: undefined method `bye' for #<Test:0x2777040> !!!
-- Modified Test class --
Hello, world
Bye, world


И все это "из коробки" для любого метода и любого класса. Другой вопрос насколько это надо и когда это стоит использовать. Но делать вручную то же самое на C++ и тяжело и вряд ли необходимо.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.11.05 10:23
Оценка: +2
Здравствуйте, mrozov, Вы писали:

M>2. Подозреваю, что даже такой высококлассный специалист, как Вы, смог бы выиграть в скорости написания кода той же степени надежности, используя не с++, а с# или Java.


Скорость написания кода, это еще не все. В Java, когда мне приходилось ей заниматься, было множество своих заморочек, которые отрицательно сказывались на скорости написания кода. Плюс, для некоторых типов задач, у Java была очень низкая скорость исполнения кода. Так что с Java у меня не сложилось.

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


Но ведь речь нужно вести о конкретных командах и конкретных проектах. Если есть команда, хорошо владеющая C++ и не допускающая того количества ошибок, о котором постоянно говорят, и эта команда специализируется в конкретной предметной области, имеет в ней свои наработки, то почему участники этой команды не могут агитировать за C++? Я вот этого не понимаю.

Т.е. лозунг "Все в .Net или Java!" -- это легально. А вот "Пишите прикладные проекты на C++" -- это уже нецензурная брань? Так получается?
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: С++ culture
От: mrozov  
Дата: 09.11.05 10:32
Оценка: +1 -1
Здравствуйте, eao197, Вы писали:


E>Давай так: перечисли те прикладные области, которые ты знаешь. Так будет проще оценивать перспективность языка.


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

Я назову две — web-программиование (все) и внутренняя автоматизация (вся). Осмелюсь утверждать, что в России другими видами программирования можно (почти) пренебречь.

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

Однако — места для с++ ни в моей работе, ни в работе моих коллег почти нет. А знакомых коллег у меня пара сотен наберется... это вроде как немало?
И в каждой из контор, с которыми я имел дело за последний год (с десяток), как в маленьких так и в очень крупных, идет процесс перевода разработок на .net.
Кроме тех, которые давно сидят на Java.

Это просто объективный процесс.
Re[7]: С++ culture
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.11.05 11:30
Оценка: +2
Здравствуйте, mrozov, Вы писали:

M>По-моему — это факт.


Спорить о вкусе устриц, как это не печально, можно только с теми, кто их ел.
... << RSDN@Home 1.2.0 alpha rev. 617>>
AVK Blog
Re[13]: С++ culture
От: Kluev  
Дата: 09.11.05 11:36
Оценка: -1 :)
Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Kluev, Вы писали:


K>>Дотнетовский массив — это ссылочный тип который в GC-хипе аллоцируется.

GZ>Ну и что?

K>>В NET нельзя сделать массив частью аггрегата, как в С++:

K>>
K>>struct Triangle
K>>{
K>>   Node  *nodes[3];
K>>};
K>>

GZ>А зачем указатели? Это оверхед.

Один узел разделяется м-ду несколькими треугольниками. А из треугольников делается сетка. Поэтому и указатели.
Массив из трех указателей, на Node. Оверхед равен нулю.

K>>В итоге имеем оверхед на ровном месте. В качестве примера цифры из реальной жизни.

K>>В программе ~150000 обьектов в которых 8 фикс.массивов на борту, ~50000 в которых 15.
K>>В С++ общее число обьектов: 200 тысяч.
K>>В .NETе 150к + 150к*8 + 50к + 50к*15 = 2,150,000

GZ>Не понял расчеты, ну да ладно.


Суть в том что сишные-фиксированные массивы не аллоцируются сами по себе в хипе, а входят в состав обьекта, и все распределяется одним махом. Дотнетовские массивы должны распределится отдельно, т.е. один аллок на обьект и + несколько на массивы. В итоге в С++ будет распределено 200к обьектов, а в NET-e почти в 11 раз больше. Чувствуешь разницу? Или память это не ресурс? Фактически GC прийдется регулярно обрабатывать больше 2 млн обьектов. И это только часть от big picture.

K>>Если смысл обсуждать дальше? Конечно можно возразить (на примере того же треугольника) делай вот так и будет щастье:

K>>
K>>class Triangle
K>>{
K>>   public Node A, B, C; // вместо массива переменные
K>>}
K>>

K>>Но это уже буллшит какой-то.

GZ>Ничего криминального не вижу. Это номальный учет особенностей среды.


Ага, а обращение по индексам будем делать так?
Node node_at( int idx )
{
   switch ( idx )
   {
      case 0: return A;
      case 1: return B;
      // понеслась 
   }
}

И не кажется ли тебе такое программирование гемором?
Re[4]: С++ culture
От: ArtemGorikov Австралия жж
Дата: 09.11.05 19:00
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>И хотя я могу показаться крамольным... Тем не менее, следует учитывать, что язык в немалой степени определяет способ мышления. Хотя, если задача, или ещё какие-либо условия мышления не требуют, то спору нет, в таком контексте бессмысленно говорить о различиях языков, API и прочих подобных вещей.

+

VD>Язык определяет сужение мышления. Люди знающий один ЯП принципиально не могут мыслить широко. А вот когда ты знашь много разных языков, то на любом языке ты можешь мысль более свободно.

++++

IMHO то же самое относится к обычным языкам — многие конструкции на английском языке просто невозможно точно передать на русском. Бывает полезно переключить мозги и мыслить именно на том конкретном языке, чтобы 100% точно понять суть сказанной фразы.

И все-таки есть один язык, который ты знаешь лучше остальных, поэтому "профессионал может писать на любом языке" не значит "профессионал раскроет все возможности любого языка и использует его наиболее продуктивно и оптимально". Ессно все IMHO
Re[13]: С++ culture
От: Kluev  
Дата: 10.11.05 08:37
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Kluev, Вы писали:


K>>В итоге имеем оверхед на ровном месте. В качестве примера цифры из реальной жизни.

K>>В программе ~150000 обьектов в которых 8 фикс.массивов на борту, ~50000 в которых 15.
K>>В С++ общее число обьектов: 200 тысяч.
K>>В .NETе 150к + 150к*8 + 50к + 50к*15 = 2,150,000

VD>Это из серии:

VD>

Назову конкретные цифры: 150, 8, 50, 15, 2150000...

VD>
Могу кусок лога показать, посчитаем с точностью до байта, полегчает от этого?

K>>Если смысл обсуждать дальше? Конечно можно возразить (на примере того же треугольника) делай вот так и будет щастье:

K>>
K>>class Triangle
K>>{
K>>   public Node A, B, C; // вместо массива переменные
K>>}
K>>

K>>Но это уже буллшит какой-то.

VD>Это подобные слова "булшит" какой-то.


VD>Индексированный доступ всего лишь абстракция. Можно реализовать ее так:

VD>

VD>    public Node this[int index]
VD>    {
VD>        get
VD>        {
VD>            switch (index)
VD>            {
VD>                case 0:  return Node1;
VD>                case 1:  return Node2;
VD>                case 2:  return Node3;
VD>                default: throw new ArgumentOutOfRangeException("index");
VD>            }
VD>        }
VD>    }

VD>

Самому не смешно?

А нужно всего-то:
struct Triangle
{
   Node *nodes[3];
   Node* node_at( int idx ) // кольцевой доступ
   {
      static const int imap[] = { 1, 2, 0, 1, 2, 0, 1 };
      return nodes[imap[idx+2]];
   }
};


VD>А можно применить ансэй и будет точно так же как на плюсах. Если при этом как следует инкапсулировать опасный код, то дальше можно работать совершенно безопасно.


А почему бы тогда сразу не на плюсах? Зачем какие-то танцы с бубном.
Re[5]: С++ culture
От: Awaken Украина  
Дата: 11.11.05 21:01
Оценка: +2
M>Т.е. Ваша личная высочайшая или даже сверхестественная квалификация ни в коей мере не отменяет того >простого факта, что большинство (подавляющее) людей не способны писать код с той степеню аккуратности, >которая требуется для грамотного кодирования на с++.

вопрос грамотного кодирования решается достаточно просто — выработкой СТАНДАРТОВ кодирования,
рекомендуемых библиотек и наработок (в т.ч. собственных). в любой программерской конторе существующей не первый день, есть свои best practices.
Re[10]: С++ culture
От: c-smile Канада http://terrainformatica.com
Дата: 11.11.05 21:45
Оценка: +1 :)
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, c-smile, Вы писали:


CS>>Если честно то я например устриц не ем.

CS>>Мне почему-то достаточно их запаха.

AVK>Но, тем не менее, о их вкусе споришь Что и требовалось доказать


Да нет, это я в том смысле что educated person в состоянии оценить
скольких он обрызгает если что
Re[20]: С++ culture
От: GU Glez  
Дата: 19.11.05 12:44
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

[skip]

На счет микроядра. Вспомните (или возьмите последенее 4-ое издание Руссиновича, стр 40, врезка, особенно последнее предложение), что там сказано по поводу микроядра — ничего общего с Вашими утверждениями. А между прочим, рецензия (да и продвижение тоже) книги — МС-овская.

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


+1000. Оригинально! А они что кушать не хотят, и занимаются исключительно теми вещами, которые исходят из из собственной философской ориентации жизненного пути в этом мире . И просто "по-человечески" их не купить. А с такими же Именами (с большой буквы), но не работающие в одной "малоизвестной" фирме — уже не авторитет. Здорово! еще плюс тыща.
С уважением,
GU Glez [Джи Ю Глиз]
Re[26]: С++ culture
От: Pzz Россия https://github.com/alexpevzner
Дата: 05.12.05 01:07
Оценка: +1 :)
VladD2 wrote:
>
> Pzz>Википедия повторяет распостраненное заблуждение.
>
> Ничего она не повторяет. Там сказано то что было на самом деле. ОС
> проектировалась как микроядерная, но в ходе разработки в ядро
> засовавались все большие и большие куски тем самым уводя ОС в сторону
> монолитных. На сегодня это гибрид.

Что именно там от микроядра?
Posted via RSDN NNTP Server 2.0
Re[17]: why off?
От: Plague Россия  
Дата: 01.04.08 11:29
Оценка: +2
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, Plague, Вы писали:


P>>Здравствуйте, VladD2, Вы писали:


VD>>>

- Вот все говорят о дотнете, а ведь это полная туфта. На нем же даже игрушку написать нельзя.
VD>>>- Помилуйте, вот игршка. Загрузите, поглядите.

P>>Например?

KV>http://www.codeproject.com/KB/mcpp/quake2.aspx


KV>Загрузите, поглядите

Я тут увидел несколько моментов:
    1. Уважаемый Кармак пишет настолько хороший код, что можно взять Quake2, изначально требующий 16мб памяти и 90Mhz процессор, скомпилировать и он заработает!
    2. Возможно легкое портирование хорошо написанных С/С++ на .NET платформу.
    3. Все-таки С++, а не С#/Nemerle... Вон даже на Хаскеле 3D игра есть...
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[20]: С++ culture
От: vdimas Россия  
Дата: 17.11.05 21:17
Оценка: 10 (1)
Здравствуйте, Sinclair, Вы писали:


V>>Понимаешь, HAL она такая штука, что ее границы можно выбирать произвольно. Если сделать высокий уровень абстракций, то львиная доля кода перекочует в тот самый unmanaged, и блоки HAL под конкретные модели конкретных железяк в все так же будут разрабатывать вне C#.

S>А зачем, собственно, произвольно выбирать ее границы? Есть довольно-таки простой критерий их выбора: надо предоставить доступ ко всему при минимальном объеме кода.

V>>Речь о том, что когда начнут вставлять реальные железки в реальные компы, то часть имплементации HAL возможно придется писать производителям железок. И не на C#.


S>Может, я чего-то не понимаю? Дело в том, что с точки зрения 86й архитектуры есть, в общем-то, ровно две абстракции: память и порты. Все. Точка. Невозможно сделать железку, которая будет работать как-то по другому. Просто потому, что процессор ни до чего другого не сможет добраться. Все железки программируются именно так. Это означает, что достаточно сделать интринсик-функции чтения/записи в порт — и всё. Остальная логика программируется через них.


S>Развей, пожалуйста, мои заблуждения.


Точка зрения понятна, но тем не менее HAL-ы делают более высокоуровневыми, чем реализации inp() и outp() стандартной библиотеки С. Развеять тебе поможет спецификация HAL тех же виндов (DDK), линухов (исходники). Сам я писал под embedded устройства, где в HAL помимо прочего входили атомарные операции (InterlockedXXX) и вывод на экран (в той операционке не было GDI, да оно и не нужно было, т.к. не требовалось общих/одинаковых операций при работе с экраном/принтером/битмапами). Так вот, реализация этих HAL была не так уж чтобы совсем тривиальна, и, разумеется, сильно засисела от конкретной железки PDA, на котором исполнялось. Даже реализация объекта ядра — таймера, сидела поверх HAL, т.к. на разных железках было разное физическое управление таймерами. Т.е. я и вел речь о том, что, по сути, границу HAL выбирают довольно-таки произвольно, в зависимости о потребностей. Например, выделять работу с таймерами в отдельный драйвер (даже если ОС построена на монолитной архитектуре) нецелесообразно, проще запихнуть в HAL и забыть.

Конкретно по 86-й архитектуре. Понимаешь, этой архитектуре сильно повезло в том плане, что для нее практически стандартизирована внешняя обвеска, т.е. DMA работает так-то, контроллер прерываний — так-то, таймеры — так-то и т.д.

Открой вкладку "Устройства" на св-ве компьютера и посмотри драйвера на различные системные устройства. На приличную часть из них выдается сообщение: "для этого устройства не требуется драйвер" (особенно на перечисленные мной).
И даже при таком раскладе, просто посмотри список экспортируемых ф-ий в system32/hal.dll. Около 100 ф-ий.

Ориентируясь же на произвольную архитектуру необходимо операционке предоставить унифицированный доступ к этим фичам. Разумеется, не через inp() и outp(), а именно через более высокий абстрактный уровень.
Re[7]: С++ culture
От: Kisloid Мухосранск  
Дата: 20.10.05 10:41
Оценка: 1 (1)
Здравствуйте, Cyberax, Вы писали:

C>И ну. Достает писать try..finally/using блоки в C#/Java, а в С++ я про

C>них уже забыл.

Кстати мня тоже это не радует, интересно, а почему бы просто не добавить плюс к управляемому хипу еще и неуправляемый ??? В таком случае я уже давно бы про С++ забыл бы...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Re[6]: С++ culture
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.11.05 23:30
Оценка: 1 (1)
Здравствуйте, VladD2, Вы писали:

VD>Речь не об абстрактном мыслительном поцессе. А о программировании где язык определяет мировозрение программиста. Мы мыслим на ЯП. Более мощьный язык позволяет описывать проблему более абстракно и просто.


Э... а определение понятия мощности языка можно? Тут когда-то бодались уже по этому поводу, да я уж подзабыл, где именно. AFAIK, LISP тут впереди планеты всей.

VD>Мысля на одном языке программист невольно ограничивает свое мировозрение принятыми в нем паттернами.


Зависит от степени, в которой язык навязывает такие ограничения. Например, Java навязывает использование GC и одиночного наследования. Ибо иного не дано. Тогда как C++ этого не делает. Lisp, кстати, тоже, если не считать GC.

VD>Другие языки дают другие подходы. И может оказаться так, что более красивое решение очевидно для пользователя одного языка, но не очевидно для другого.


Да, это может быть так, только вот связывать доступность решения с опытом использования того или иного языка неправомерно. Одно и тоже решение (скажем, замыкания) может быть описано и на Lisp, и для С# и в терминах object pascal, однако сути самого решения это не изменит. Равно как и его доступности, скажем, тому, кто знает паскаль, но не знает Lisp.

VD>Зная несколько языков программист способен более трезво смотреть на проблему выбирая те подходы которые ниболее удобны в данном случае.


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

ГВ>>Это всё, что необходимо. Хотя я не буду спорить с тем, что знакомство с подходами, предлагаемыми другими языками (API и пр.) может помочь в том смысле, что подскажет какой-то незатёртый ход, идею и т.п. Но само по себе оно не определяет ни широты мышления, ни уровня абстракции излагающего. Более того, может даже мешать (ты и сам по этому поводу много высказывался ).


VD>Мешать вряд ли.


Ну вот! А как же догмы и прочее, что впитываетя с мол... кхм, с каждым прочтением, например, стандарта?

VD>Но несомненно кроме владения несколькими языками нжно еще и "мозги на плечах".


+3

VD>Просто сам факт владения уже говорит о многом.


Угу, например — о любопытстве.

ГВ>>А иначе не было бы дураков-полиглотов. Да и вообще, тогда многознание можно было бы приравнять к великому уму, что не есть правильно.


VD>Полиглот обычно зазубривает информацию не вдаваясь в ее суть. Конечно можно тупо выучить синтаксис нескольких языков не вдаваясь в их концепции и не понимая как их применять в жизни. Но это уже совсем клинический случай испорченности ДНК. С таким ДНК нужно идти в справочную или в библиотеку, но не программистом.


+1

VD>>>И какого же? У Явы дцать родителей. У Шарпа не меньше. Или схожесть синтаксиса определяет все что можно?

ГВ>>C++, разумеется.
VD>Ты опять не вдиел дискусси о этому поводу. Мне кажется там доходчиво было показано, что С++ для Шара всего лишь один из родственников и далего не самый концептуальный.

Да видел я эту дискуссию. А потом, я разве говорил, что Java унаследована только от C++? Просто мне кажется, что Java заполучит аудиторию C/C++-программистов несколько легче и быстрее, чем, например, тех же Smalltalk-еров. А лёгкость сия связана с тем, что культура Java близка культуре C++ в силу того, что C++ есть в родителях Java.

ГВ>> Он есть в родителях Java? Есть. С чего начинается изучение языка? С синтаксиса. Синтаксис близок к C++? Ещё как близок!

VD>Синтаксис скорее похож. Все же в Шарпе тонны синтаксических конструкций отсуствующих в С++. Даже принцип парсинга файлов и тот иной. Если уж на то пошло, то синаксис и С++ и C# заимствованы у С. А у С++ и C# схожи скорее только ключевые слова. Тот же синтаксис описания классов совсем иной.

Я и не говорю о 100% совпадении. Я апеллирую только к близости синтаксисов.

ГВ>> Семантика бОльшей части операторов и объявлений близка к C++? Ещё как близка!

VD>Если про синтаксис еще можно поспорить, то говорить о схожести семантики я бы точно не стал. Что там близкого?

Простейшие вещи, разумеется. Объявления переменных и констант, арифметика, операторы, вызовы функций.

ГВ>> Дык, для какой группы программистов облегчён переход на Java? Правильно — для C++-ников.

VD>Да не правильно вовсе. Дельфисты на нее тоже переходят в лет. Причем проблем с ломкой сознания куда меньше.

Ну, если не забывать, что Дельфи через object pascal (и turbo pascal v.5.5+) тоже заполучила некоторую часть C++-культуры...

ГВ>> Что они принесут? Правильно, мутировавшую C++-культуру. Ergo, "Java-культура" в немалой степени наследует C++-культуру и именно её!

VD>Да вот как раз Ява, и темболее C# имеют совсем иную культуру. Это чистые ООЯ. Причем это еще и динамические языки. Для хорошего понимания Явы и C# нужно скорее знать COM и Смолток, так как концепции там куда ближе.

Значит, добавим к исходному тезису утверждение, что на Java несложно перейти со Smalltalk.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: С++ culture
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.11.05 10:18
Оценка: 1 (1)
Здравствуйте, VladD2, Вы писали:

E>>Можно ли в Java вводить новые методы в уже существующие классы?


VD>Да. На том построена туча фрэймворков.


Кстати. Требуется помощь зала по жабке. Есть некий класс A.
Создадим его экземпляр так:

A a = new A() {public void newMethod() {/* do nothing */};};

Как можно вызвать этот новый метод не прибегая к рефлексии?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[17]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.11.05 11:22
Оценка: 1 (1)
Здравствуйте, mrozov, Вы писали:

E>>Давай так: перечисли те прикладные области, которые ты знаешь. Так будет проще оценивать перспективность языка.


M>Давайте все-таки на вы, если это не противоречит Вашим религиозным убеждениям.


Ok.

M>Я назову две — web-программиование (все) и внутренняя автоматизация (вся). Осмелюсь утверждать, что в России другими видами программирования можно (почти) пренебречь.


M>Это не значит, что их нет, что они не имеют права на существование, что они в чем-то хуже. Просто их меньше.


И?
Тем, кто работает в этих областях какой смысл обращать внимание на web-программирование и внутреннюю автоматизацию?
Я, например, занимался АСУТП и системами реального времени. Притягивать туда за уши .Net и Java? Есть и в этих областях место для таких языков, для предоставления того же web-интерфейса. Но это не mission-critial код.
Сейчас я связан с телекоммуникационными задачами. С++ здесь себя нормально чувствует. А требования к софту очень серьезные, поэтому дешевле набирать или готовить хороших специалистов, которые в состоянии будут программировать на C++, чем переходить на Java/.Net в надежде на более простой подбор персонала.

M>Это просто объективный процесс.


Хорошая фраза есть в начале этой темы:

просто новые технологии с рынка не уходят — они его расширяют


Веб-программирование -- это интересно, конечно, актуально на данный момент и здесь нет тотального доминирования Java/.Net -- масса сайтов крутится на PHP, Python, Perl и даже Ruby. Но ведь Веб-программирование совершенно не убило задачи АСУТП, CAD или встраиваемых систем. Просто появился новый рынок, который сейчас всасывает кучу ресурсов. Какое-то время так и будет продолжаться. И если кто-то будет кричать: "Создавайте веб-приложения на C++", то это действительно будет смахивать на авантюру (хотя никто не исключает возможности появления супер-пупер фрейморка на C++ для разработки веб-приложений -- учитывая низкие требования к ресурсам C++ программ это может стать неприятным сюрпризом для JSP и ASP решений ). Однако, лозунг "Создавайте распределенные приложения на C++" совсем не такой дикий, каким может показаться. И есть масса предметных областей, где этот лозунг будет очень актуальным.

Так что, в областях, где C++ был, выдавить его будет очень не просто. Возьмите, к примеру Smalltalk или Prolog -- ну очень экзотические языки, тем не менее применяются и продукты на их основе никто не бросается переделывать на других языках. Новые области активно используют .Net и Java. Однако:
— во-первых, сейчас виден возрастающий интерес к динамическим языкам, т.к. Python, тот же Smalltalk, Ruby и др. Возможно, в скором времени это будет новый мейнстрим, который создаст новые рыночные ниши и будет доминировать в них над C++/C#/Java вместе взятыми;
— во-вторых, для меня совсем не факт, что C++ утратит актуальность и не сможет найти себе новое применение. Рост гигагерцев замедляется, развиваются разные умные устроства, у которых производительность, все же, не самая большая. Поэтому и быстрые, экономичные приложения могут в ближайшее время вернуть себе заслуженное внимание. Qtopia, написанная на C++, например, совсем не плохо себя чувствует.

Так что реплики "Делайте прикладные проекты на C++", имхо, весьма умесны. Просто нужно указывать, к чему именно они должны прикладываться.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: С++ culture
От: vdimas Россия  
Дата: 16.11.05 17:41
Оценка: 1 (1)
Здравствуйте, mrozov, Вы писали:

M>Все так. Или почти так.


M>Просто если принять как данность, что кодирование на голом с++ — вещь неправильная, то следующий логичный шаг — использовать язык/среду, в которой соответствующие проблемы были устранены изначально.


M>Раньше особого выбора просто не было. Теперь есть.


Согласен. Дотнет отберет прилично задач не только у Явы, но и у С++. Ну и на здоровье. Самое правильное — использовать наиболее подходящий инструмент для каждой задачи. С++ приобретет легкий оттенок "системного" языка, а про С мы наверно забудем.
Re[23]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.12.05 20:59
Оценка: 1 (1)
Здравствуйте, Pzz, Вы писали:

Pzz>NT никогда не была микроядерной ОС. Ядро НТ монолитно,


Windows NT microkernel
http://en.wikipedia.org/wiki/Windows_NT

Pzz>Ух, я этого не знал. Т.е., MS-DOS (Windows 3.1), но с защитой при

Pzz>компиляции. Прекрасная ОС, ничего не скажешь...

В MS-DOS небыло ни процессов ни, ни сообщений, ни потоков. Короче нихрена в ней небыло.
Сингулярити это скорее нечто на тему Оберон-ОС.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: С++ culture
От: Cyberax Марс  
Дата: 20.10.05 10:27
Оценка: +1
sch wrote:

>> Это-то фигня. Больше всего раздражает, что GC уничтожает память

>> недетерминировано. А значит RAII и подобные идиомы не проходят.
> Ну и?

И ну. Достает писать try..finally/using блоки в C#/Java, а в С++ я про
них уже забыл.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 2.0 beta
Sapienti sat!
Re[2]: С++ culture
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 02.11.05 23:39
Оценка: +1
Здравствуйте, sch, Вы писали:

sch>А я вот честно говоря не понимаю причин, по которым спорят о преимуществах одних языков над другими языками, одних API над другими API, одних компиляторов над другими компиялторами. По моему скромному мнению, профессионал может работать с любыми языками, средставами, API, девкитами и прочим; все что нужно, для того, чтобы быть производительным -- компьютер, тишина и немного кофе.


И хотя я могу показаться крамольным... Тем не менее, следует учитывать, что язык в немалой степени определяет способ мышления. Хотя, если задача, или ещё какие-либо условия мышления не требуют, то спору нет, в таком контексте бессмысленно говорить о различиях языков, API и прочих подобных вещей.

sch>Поймите меня правильно. Я программирую на C++, я люблю этот язык, знаю его норов, знаю тонкости его использования. Но если завтра мне будет нужно писать на C# -- я буду писать на C#, если будет нужно писать на Java -- буду писать на Java, а каким красивым и изящным может быть код на GW-BASIC... По моему скромному мнению, новый язык -- это здорово: можно взглянуть на кажущиеся неприступными истины.


Только не забудь, плз., что: "Я программирую на C++, я люблю этот язык, знаю его норов, знаю тонкости его использования". А теперь вспомним, наследниками культуры какого-конкретно-языка являются и Java, и C#.

sch>Долой вражду на основе языков программирования.

sch>Да здравствует языковый космополитизм.

А кто бы спорил?!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.05 00:50
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

C>Это-то фигня. Больше всего раздражает, что GC уничтожает память

C>недетерминировано. А значит RAII и подобные идиомы не проходят.

Нда, невежество в вопросах ЖЦ просто порожает. Ну, откуда ты взял, что ЖЦ уничтожает память? И чем тебе не угодил using?

>> GC из .NET -- не ужасен, просто он несколько /другой/. Именно это и

>> пугает.

C>GC? Пугает? Хахахахаха.....


Действительно. Как может пугать то о чем даже понятия не имешь?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.05 00:50
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>И хотя я могу показаться крамольным... Тем не менее, следует учитывать, что язык в немалой степени определяет способ мышления. Хотя, если задача, или ещё какие-либо условия мышления не требуют, то спору нет, в таком контексте бессмысленно говорить о различиях языков, API и прочих подобных вещей.


Язык определяет сужение мышления. Люди знающий один ЯП принципиально не могут мыслить широко. А вот когда ты знашь много разных языков, то на любом языке ты можешь мысль более свободно.

ГВ>Только не забудь, плз., что: "Я программирую на C++, я люблю этот язык, знаю его норов, знаю тонкости его использования". А теперь вспомним, наследниками культуры какого-конкретно-языка являются и Java, и C#.


И какого же? У Явы дцать родителей. У Шарпа не меньше. Или схожесть синтаксиса определяет все что можно?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.11.05 14:41
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

VD>>И какого же? У Явы дцать родителей. У Шарпа не меньше. Или схожесть синтаксиса определяет все что можно?


ГВ>C++, разумеется. Он есть в родителях Java? Есть. С чего начинается изучение языка? С синтаксиса. Синтаксис близок к C++? Ещё как близок! Семантика бОльшей части операторов и объявлений близка к C++? Ещё как близка! Дык, для какой группы программистов облегчён переход на Java? Правильно — для C++-ников. Что они принесут? Правильно, мутировавшую C++-культуру. Ergo, "Java-культура" в немалой степени наследует C++-культуру и именно её!


ГВ>Точно такая же наследственность у C#. Только его, правда, в кашу превратят скоро, но сейчас это к делу не относится.


Геннадий, ты пропустил нашу драку с Владом по этому поводу Re[18]: Следующий язык программирования
Автор: eao197
Дата: 08.10.05
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.05 18:00
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Не согласен. Свобода изложения мысли складывается из:


ГВ>- понимания цели (задача + контекст);

ГВ>- наличия мысли;
ГВ>- владения средством изложения мысли.

Речь не об абстрактном мыслительном поцессе. А о программировании где язык определяет мировозрение программиста. Мы мыслим на ЯП. Более мощьный язык позволяет описывать проблему более абстракно и просто. Мысля на одном языке программист невольно ограничивает свое мировозрение принятыми в нем паттернами. Другие языки дают другие подходы. И может оказаться так, что более красивое решение очевидно для пользователя одного языка, но не очевидно для другого. Зная несколько языков программист способен более трезво смотреть на проблему выбирая те подходы которые ниболее удобны в данном случае.

ГВ>Это всё, что необходимо. Хотя я не буду спорить с тем, что знакомство с подходами, предлагаемыми другими языками (API и пр.) может помочь в том смысле, что подскажет какой-то незатёртый ход, идею и т.п. Но само по себе оно не определяет ни широты мышления, ни уровня абстракции излагающего. Более того, может даже мешать (ты и сам по этому поводу много высказывался ).


Мешать вряд ли. Но несомненно кроме владения несколькими языками нжно еще и "мозги на плечах". Просто сам факт владения уже говорит о многом.

ГВ>А иначе не было бы дураков-полиглотов. Да и вообще, тогда многознание можно было бы приравнять к великому уму, что не есть правильно.


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

VD>>И какого же? У Явы дцать родителей. У Шарпа не меньше. Или схожесть синтаксиса определяет все что можно?


ГВ>C++, разумеется.


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

ГВ> Он есть в родителях Java? Есть. С чего начинается изучение языка? С синтаксиса. Синтаксис близок к C++? Ещё как близок!


Синтаксис скорее похож. Все же в Шарпе тонны синтаксических конструкций отсуствующих в С++. Даже принцип парсинга файлов и тот иной.

Если уж на то пошло, то синаксис и С++ и C# заимствованы у С. А у С++ и C# схожи скорее только ключевые слова. Тот же синтаксис описания классов совсем иной.

ГВ> Семантика бОльшей части операторов и объявлений близка к C++? Ещё как близка!


Если про синтаксис еще можно поспорить, то говорить о схожести семантики я бы точно не стал. Что там близкого?

ГВ> Дык, для какой группы программистов облегчён переход на Java? Правильно — для C++-ников.


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

ГВ> Что они принесут? Правильно, мутировавшую C++-культуру. Ergo, "Java-культура" в немалой степени наследует C++-культуру и именно её!


Да вот как раз Ява, и темболее C# имеют совсем иную культуру. Это чистые ООЯ. Причем это еще и динамические языки. Для хорошего понимания Явы и C# нужно скорее знать COM и Смолток, так как концепции там куда ближе.



ГВ>Точно такая же наследственность у C#. Только его, правда, в кашу превратят скоро, но сейчас это к делу не относится.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.05 18:00
Оценка: :)
Здравствуйте, GU Glez, Вы писали:

GG>Вообще-то, это говорил Достоевский


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

GG>и об этом говорят многие ученые.


Ну, да... нам ученым...

GG> Но это так к сведению.


Спасибо. Сведения очень позновательные.

GG> Меня всегда удивляет одно — где можно найти профессионального врача владеющего всеми (или очень многими) областями медицины?


Хм. Наверно таких враченй называют педиаторами. Но к делу это вряд ли относится.

GG> Не помню кто сказал, но думаю это рядом с истиной: "Профессионал во всем — зовется дилетант". Хотя, с утверждением, что программирование — область в которой необходимо постоянно изучать и "мыслить как можно лучше", путем изучения нового — думаю согласятся многие.


Вообще-то я вел речь не о глубоких знаниях всего насвете. Я говорил о ЯП. ЯП это нечто большее чем просто чем просто язык. Он определяет мироваозрение. С++-программист никогда не поймет Ява-, ВБ- или Смолток-программиста. Как, в прочем, и на оборот. Но если встречются два программисто знащих перечисленные языки, то ни будут прекрасно понимать друг-друга даже если в данный момент каждый из них использует отличный от другого язык.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: С++ culture
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.11.05 20:19
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Хм. Наверно таких враченй называют педиаторами. Но к делу это вряд ли относится.


Терапевтами наверное? Педиатр это детский врач. Хотя у них тоже довольно широкий спектр умений нужен.
Впрочем неважно. Главное что в мед. училище все студенты изучают и фармакологию, и хирургию, и патологоанатомию и много чего еще. А вот некоторые программисты почему то считают что знания одного C++/Delphi/C# etc достаточно для того чтобы считать себя высококлассными спецами. Пример — Основы. Что это?
Автор: kilonet2
Дата: 29.10.05
.

VD>Вообще-то я вел речь не о глубоких знаниях всего насвете. Я говорил о ЯП. ЯП это нечто большее чем просто чем просто язык. Он определяет мироваозрение. С++-программист никогда не поймет Ява-, ВБ- или Смолток-программиста. Как, в прочем, и на оборот. Но если встречются два программисто знащих перечисленные языки, то ни будут прекрасно понимать друг-друга даже если в данный момент каждый из них использует отличный от другого язык.


Что забавно — совсем не обязательно изучать какую то экзотику. Даже широко используемый в индустрии XSLT будет полезен для расширения кругозола. Можно еще вспомнить Ant/NAnt/MSBuild.
... << RSDN@Home 1.2.0 alpha rev. 619 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[8]: С++ culture
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.11.05 07:14
Оценка: +1
Здравствуйте, GU Glez, Вы писали:

GG>Правильно. Но и мы — тех. специалисты — на факультетах изучаем историю, философию, социологию и т.д. и т.п.


Они, медики, тоже изучают. Речь о другом — если мед. ВУЗов в советское время было предостаточно, и практически все врачи имеют профильное высшее образование (у нас даже в аптеке лекарства без высшего образования продавать нельзя). А вот с программированием ситуация куда печальнее — с профильным образованием, даже если брать самую верхушку, меньше половины. Основная мапсса просто с техническим, математическим, физическим образованием. Немало с гуманитарным. А есть вобще без высшего образования.
Поэтому знакомство каждого конкретного программиста со все спектром современных техник программирования лежит целиком на его совести.

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


Лучше день попотеть, потом за час долететь.
... << RSDN@Home 1.2.0 alpha rev. 619 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[9]: С++ culture
От: GU Glez  
Дата: 05.11.05 08:35
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

AVK>Они, медики, тоже изучают. Речь о другом — если мед. ВУЗов в советское время было предостаточно, и практически все врачи имеют профильное высшее образование (у нас даже в аптеке лекарства без высшего образования продавать нельзя). А вот с программированием ситуация куда печальнее — с профильным образованием, даже если брать самую верхушку, меньше половины. Основная мапсса просто с техническим, математическим, физическим образованием. Немало с гуманитарным. А есть вобще без высшего образования.

AVK>Поэтому знакомство каждого конкретного программиста со все спектром современных техник программирования лежит целиком на его совести.
Думал не отвечать, но тогда останется незамеченным один очень важный факт. Аналогия с медиками с моей стороны была приведена в качестве примера, дабы показать, что даже в такой области, где все меняется не так быстро (новые методы лечения и диагностирования появляются только после длительных тестов), то даже здесь почти нет Професиионалов знающих все или почти все и могущих работать без ухудшения качества работы на замещаемой должности (деревенские больницы и больницы малых городов во внимание не приниманем).
А что мы имеем в программировании. Мало того что по идее надо бы знать пяток-десяток другой ЯП и Технологий, так еще и следить за их движением в области развития, которое происходит довольно таки часто.
В университете писал на Asm, C (C++ — не признавал по идеологиским соображениям), Delphi и FreePascal. Начиная с 3-го курса проводил переодически мастер-класс для некоторых преподавателей (извините за нескромность, далее по тексту Вы поймете о чем речь). Однако, сейчас я не могу без отрывы от производства сесть и сделать тоже самое как на Delphi, так и на VC++. Произойдет ломка сознания. В памяти даже работа с COM (какой бы сложной она не была на VC++, про ATL молчу — это еще один новый слой абстракции) осталась именно в качестве примеров на VC++ (и живут поныне ). А Delphi — хоть и проще с КОМ работать, но мне например сложно вот так взять и продолжить писать программу, начатую моим коллегой (у нас в городе их аж 7 человек ). Да что там коллегой, ко мне обратились студенты из университета, где я учился. Принесли и показывают мою дипломную работу (писана Delphi практически без VCL (лишь некоторые модули) для большей совместимости с FreePascal и иму подобными) и тычуть пальцем: "мол как ты тут делал? Что это такое и почему?". В ответ им два слова — "не помню". Приходите тогда-то постараюсь вспомнить. Ну и что? Вспомнить-то вспомнил, а вот помочь им в их вопросах и помочь дописать (читай разобраться в некоторых вопросах) их диплом так и не смог — не выдержал ломки от синтаксиса и вообще отвык от "begin..end" и то что комментарии — "{}", указателей, взятие адреса и т.д. и т.п. Вообщем, дал им свои старые записи, ребята как-то выкрутились.
ЗЫ. Те самые преподаватели — предоподаватели математики и физики. Факультет Информатики открыли только в позапрошлом году.
С уважением,
GU Glez [Джи Ю Глиз]
Re[7]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.11.05 06:20
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

VD>>Да вот как раз Ява, и темболее C# имеют совсем иную культуру. Это чистые ООЯ. Причем это еще и динамические языки. Для хорошего понимания Явы и C# нужно скорее знать COM и Смолток, так как концепции там куда ближе.


ГВ>Значит, добавим к исходному тезису утверждение, что на Java несложно перейти со Smalltalk.


А утверждение ли это?
Как C++ники на Java переходят, я видел. А вот переходят ли на Java Smalltalk-еры (по собственной воле) -- это еще вопрос.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.11.05 13:49
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>Можно ли в Java вводить новые методы в уже существующие классы?


Да. На том построена туча фрэймворков.

E>Можно ли в Java изымать существующие методы из уже существующих классов?


Опять же да. Если бы это было невозможно, то разных Spring-ов просто не существовало бы.

E>Подгружать новые модули с новыми классами и объектами?


Тоже да.

E> Да ты же сам мне недавно доказывал, что через COM на C++ это уже давно можно было делать.


Ком является отдельной и не маленькой технологией.

E>Компилировать новые модули и подгружать их в уже работающую программу? Да на C++ -- нет проблем: запускаем внешний компилятор, строим DLL и полный вперед. А если компилятор оформлен в виде DLL или COM-объекта, то прямо из приложения можно это делать.


Ага. Вот только ни одного так и не оформелно в виде ДЛЛ. А теоритически можно. Вот только работать такие приложения будут ну очень медленно. Ведь компиляция С++ — жто процесс порой очень долгий.

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

E>Единственное проявление динамизма Java, которое приходит мне в голову -- это возможность вызова либого метода объекта через reflection с передачей аргументов в виде object[]. Только, имхо, маловато этого, чтобы динамическим языком называться. Поэтому, как мне кажется, динамизм некоторых языков сильно преувеличивается.


Ты судишь о том, что знаешь очень поверхносно. Я яву тоже знаю не очень глубого, но и моих знаний досточно чтобы заметить что твои суждения явно не верны.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.11.05 16:33
Оценка: +1
Здравствуйте, VladD2, Вы писали:

E>>Можно ли в Java вводить новые методы в уже существующие классы?


VD>Да. На том построена туча фрэймворков.


Каких?

E>>Можно ли в Java изымать существующие методы из уже существующих классов?


VD>Опять же да. Если бы это было невозможно, то разных Spring-ов просто не существовало бы.


Я думаю, что пора просить помощи у знатоков Java в этом вопросе. Лично я не могу представить себе такого кода на Java:
// SomeClass.java

public class SomeClass
{
    public void hello()
        {
            // трам-пам-пам...
        }
}

и где-то в другом файле:
public class SomeClass
{
    public void bye()
        {
            // трам-пам-пам...
        }
}

И затем:
public class SomeClassTest
{
    static public void main( string args[] )
        {
            SomeClass s = new SomeClass();
            s.hello();
            s.bye();
        }
}




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

E>>Единственное проявление динамизма Java, которое приходит мне в голову -- это возможность вызова либого метода объекта через reflection с передачей аргументов в виде object[]. Только, имхо, маловато этого, чтобы динамическим языком называться. Поэтому, как мне кажется, динамизм некоторых языков сильно преувеличивается.


VD>Ты судишь о том, что знаешь очень поверхносно. Я яву тоже знаю не очень глубого, но и моих знаний досточно чтобы заметить что твои суждения явно не верны.


Если в отношении добавленя/изъятия методов классов я прав, то мне кажется, что динамизм Java слишком завышен.

Кстати, а в C# возможно добавление/изъятие методов в класс, после того, как класс уже будет полностью определен?
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.11.05 16:33
Оценка: +1
Здравствуйте, sch, Вы писали:

E>>И все это "из коробки" для любого метода и любого класса. Другой вопрос насколько это надо и когда это стоит использовать. Но делать вручную то же самое на C++ и тяжело и вряд ли необходимо.


sch>Согласен с тобой по всем пунктам.


sch>Тут просто действует общее правило, которое заключается в том, что на C++ можно делать *все*, только напильником поработать надо


Угу. Только, к сожалению, объем доработок напильником может быть настолько велик, что ценность полученного результата окажется несоизмеримо меньше стоимости затраченных усилий.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.11.05 05:47
Оценка: +1
Здравствуйте, VladD2, Вы писали:

E>>Может быть на уровне манипуляций с байт-кодом Java и можно что-либо подобное делать, но к языку Java это оношения уже не будет иметь.


VD>Ну, конечно. А к чему интересно имеет? Спринги и т.п. как раз так и устроены. Они дают декларативный интерфейс к динамическим возможностям среды. А в основе лежат рефлексия, кодогенерация и динамическое создание экземляров.


Динамическое создание экземпляров -- это совсем не то, что изменение интерфейса класса путем добавления/изъятия методов в него.

Ты же утверждал:

E>Можно ли в Java вводить новые методы в уже существующие классы?

Да. На том построена туча фрэймворков.

что можно изменять интерфейс уже определенного класса.

E>>Кстати, а в C# возможно добавление/изъятие методов в класс, после того, как класс уже будет полностью определен?


VD>Несколькими способами. От RealProxy до эмита.


А где примеры можно посмотреть?

VD>Вот только ты почему-то считашь, что динамичность языка определяется добавлением кода в рантайме. Как раз это нужно довольно редко. А вот создать и проинциализировать объект основываясь только на его описании полученном в рантайме — это задача очень частая. В плюсах без создания специального фрэймворка (или использования разных КОМ-ом) не решаемая.


Скорее это говорит не о динамизме языка, а о динамизме программ на этом языке. А вот добавление или изменение кода в рантайме -- это как раз показатель динамизма языка. ИМХО.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: С++ culture
От: mrozov  
Дата: 08.11.05 07:37
Оценка: -1
Здравствуйте, Cyberax, Вы писали:


C>Твоя мысль понятна. Но судишь ты о мало тебе знакомой проблеме. Вообще

C>странная ситуация. Все кто пользуется С++ не находят проблем в
C>описаваемых теоретиками случаях.

Наглая и беспринципная ложь, коллега!


Я работал с С++ много лет и любил этот язык, но то, что эти проблемы действительно являются проблемами — всегда знал и видел. Перешел на .net при первой же возможности и меня тошнит каждый раз, когда приходится возвращаться к программированию на c++.

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

Smartpointer-ов действительно не хватает, но в сравнении с другим — это воистину мелочи. Собственно, если бы меня в с++ заставили использовать using, но взамен дали бы единую и согласованную систему исключений с автоматическим поднятием stack trace — согласился бы не задумываясь.

А вообще — есть еще отдельные товарищи, которые утверждают, что лучше фортрана языка нет и не будет. Правда, в наше время у них с достойной оплатой труда некоторые проблемы
Re[3]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.11.05 08:17
Оценка: +1
Здравствуйте, mrozov, Вы писали:

M>Даст бог — через какое-то время ситуация изменится и останутся только действительно грамотные люди. Но до тех пор, пока отдельные товарищи гонят волну истерии и призывают писать на с++ прикладные проекты как правило, этого ждать не приходится.


А вот мне интересно: вот у меня, к примеру, уже не помню когда были проблемы с утечками памяти. И с повисшими указателями. И с выходами за пределы массивов. И с чем там еще, чего в C++ все так боятся. Программирую на C++ довольно плотно, получается где-то по 2-3 тысячи отлаженных строк в месяц. Когда читаю многие здешние посты про паталогические проблемы C++ проявляющиеся на каждом шагу, то постоянно задаюсь вопросом: "Что же я делаю не так?"

И что, мне нужно, как правило, не выбирать C++ в качестве основного языка для реализации прикладных проектов?
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.11.05 11:56
Оценка: +1
Здравствуйте, mrozov, Вы писали:

M>Java — рулит. Но у нее есть фатальный недостаток — ее создал не MS. Причем я не шучу.

+1

Правда, за ней, кроме Sun, стоят такие монстры, как IBM и HP. Но, видимо, Java продолжит рулить в нише серверов и Unix-ов. А на Windows и десктопах MS ее уделает.

M>Короче — если мыслить с позиции человека, который отвечает за разработку, то выбор очевиден. C++ только там, где этого нельзя избежать.

M>Из любого правила есть исключения, но общая тенденция такова.

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

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


Так ведь так оно и есть.
Нет, не серьезно -- так и есть.

M>И за долгие и многочисленные часы нашего общения на эту тему мне так и не удалось довести до его сознания простую мысль — он в меньшинстве и распространять свой опыт на окружающих автоматически — совершенно некорректно. Вас мне убедить тоже, очевидно, не удастся.


Не-а. Я ведь, с недавних пор, сам стал сторонником Ruby. Теперь что-то делаю на C++, что-то на Ruby. Классно!
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: С++ culture
От: mrozov  
Дата: 08.11.05 13:10
Оценка: :)
K>Есть такая отрасль CAD/CAE/CAM называется.

А еще есть отрасль под общим названием "прикладное программирование", в которой задействовано подавляющее большинство разработчиков.

K>Только исключений слишком много.

Я вижу очень мало. А я по меркам большинства моих коллег — хардкорщик.


K>
K>class CSharpTriangle
K>{
K>  public Node[] nodes = new Node[3]; // все приехали, можете закрывать свою лавочку
K>}
K>


Контраргумент:

x = x + 1;
Re[10]: С++ culture
От: GlebZ Россия  
Дата: 08.11.05 17:39
Оценка: +1
Здравствуйте, Kluev, Вы писали:

K>Для примера достаточно одной таблетки — простой класс треугольник:

K>
K>class CSharpTriangle
K>{
K>  public Node[] nodes = new Node[3]; // все приехали, можете закрывать свою лавочку
K>}
K>


Я сам могу привести кучу аргументов против Net в CAD системах, но Холмс, почему нужно закрывать лавочку именно здесь?

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: С++ culture
От: mrozov  
Дата: 09.11.05 10:42
Оценка: +1
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это ваш опыт. Не пытайтесь его обобщать в категоричной форме на всех.


Нет, не мой. Это опыт трех компаний, в которых я работал (одна — очень крупная) и нескольких, делами которых я интересовался.
Это позволяет мне делать некоторые обобщающие выводы. А про "на всех" пусть остается на Вашей совести.

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


ПК>Зря вы не применяете этого же подхода к себе.


И опять не угадано ни одной буквы! То, что я в меньшинстве со своим пониманием опасности вызова CreateThread, я-то как раз прекрасно понимаю. А вот Вы в своей башне из слоновой кости бум web-программирования, похоже, благополучно проспали. Мир изменился.
Re[6]: С++ culture
От: mrozov  
Дата: 09.11.05 10:45
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

Колега, не нужно меня убеждать в том, что на с++ можно писать работоспособный код. Я этим занимался на протяжении немалого количества лет и даже учил этому других.
Просто делать то же самое с помощью .net заметно проще, да и порог вхождения "в клуб" заметно ниже.

По-моему — это факт.
Re[19]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.11.05 11:48
Оценка: +1
Здравствуйте, mrozov, Вы писали:

M>В общем-то, ни с чем из сказанного Вами я спорить не собираюсь. В смысле, я не совсем согласен, но придираться к словам не буду — в целом Вы абсолютно правы.

M>



PS. В следующий раз предлагаю общаться на "ты" -- так проще.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: С++ culture
От: Kluev  
Дата: 09.11.05 12:01
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

GZ>Честно говоря если бы данная задача стояла бы у меня под dotnet, я бы делал совсем по другому. Инстанцировалось бы только на момент операции, трианглы были immutable, и легко собирались бы в нулевом поколении. Конечно со стороны все кажется легко и решение за пять секунд — очень субьективно.

В CAD-ах трианглы используются как правило в двух случаях.
1) для отрисовки поверхностей. инстанцировать во время отрисовки, проще сразу застрелится
2) для расчета. Т.е. создается расчетная сетка и модифицируется п омере надобности. Т.е. из песни слова не выкинешь.


GZ>Зачем, лучше так

GZ>
GZ>Node next_node()
GZ>{
GZ>  yeald return A;
GZ>    yeald return B;
GZ>    yeald return C;
GZ>}
GZ>

GZ>
GZ> В сях такого нет.
GZ>С уважением, Gleb.

Видишь ли, просто перебрать узлы типа foreach, таких задач нет вообще.
Зато очень часто надо получать сторону: node(i); node(i+1);
Или угол: node(i-1); node(i); node(i+1);
Или просто получить соседей. Тогда по указателю находим индекс и дальше node(idx-1); node(idx+1)

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

Про шаблоны для всякой геометрии типа Point<3,double> и т.п. я уже вообще молчу. тут альтернатив плюсам нет.
Re[17]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.05 00:32
Оценка: :)
Здравствуйте, mrozov, Вы писали:

E>>Давай так: перечисли те прикладные области, которые ты знаешь. Так будет проще оценивать перспективность языка.


M>Давайте все-таки на вы, если это не противоречит Вашим религиозным убеждениям.


Здесь принято гворить "на ты". Более того, когда народ доходит до оскорблений, то зачастую переходит "на Вы".

Так что говорить "на Вы" тут никто не запрещает, но и обижаться на ты не стоит.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.05 15:50
Оценка: -1
Здравствуйте, Кузнецов Денис Викторович, Вы писали:

КДВ>Исследования, на то они и исследования, чтобы ошибаться.


Исследования делаются, чтобы проверить свои суждения, а не чтобы ошибаться. Чтобы ошибаться достаточно что-то начать делать.

КДВ> Причем часто. А реальная применимость где?


А где были реальные применения знаний по ядерной физике до появления ректоров и бомб? Знамо где в научно-исследовательских институтах.

КДВ> Где скачать, установить и как реально можно использовать?


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

КДВ> Они хоть на бумаге могут писать эти драйвера. Это ж Research!!!


А какая разница? Я не призивал использовать Сингулярити для создания копрпоротивных веб-порталов. Я просто заметил, что есть таки вполне разумные люди — ученые, которые пишут драйверы на C#. Пускай это пока что игрушка ученых, но идея эта уже далеко не бредовая.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.11.05 15:57
Оценка: +1
Здравствуйте, VladD2, Вы писали:

K>>А нужно всего-то:

K>>
K>>struct Triangle
K>>{
K>>   Node *nodes[3];
K>>   Node* node_at( int idx ) // кольцевой доступ
K>>   {
K>>      static const int imap[] = { 1, 2, 0, 1, 2, 0, 1 };
K>>      return nodes[imap[idx+2]];
K>>   }
K>>};
K>>


VD>За такой код в промышленных системах нужно по началу лишать премий, а потом выгонять если не прочувствушь. Это называется начхание на инкапсуляцию.


А можно ли раскрыть эту тему по подробнее? Что именно плохо в приведенном коде (особенно с поправкой на то, что это врядли в точности тот код, который используется в реальной системе, а больше похож на быструю "выжимку" из оного)?
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: С++ culture
От: Кузнецов Денис Викторович Казахстан  
Дата: 11.11.05 03:25
Оценка: -1
Здравствуйте, eao197, Вы писали:


VD>>За такой код в промышленных системах нужно по началу лишать премий, а потом выгонять если не прочувствушь. Это называется начхание на инкапсуляцию.


E>А можно ли раскрыть эту тему по подробнее? Что именно плохо в приведенном коде (особенно с поправкой на то, что это врядли в точности тот код, который используется в реальной системе, а больше похож на быструю "выжимку" из оного)?


Не обращай внимания. Он по своей дурацкой привычке оппонента зачморить пытается.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[20]: С++ culture
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.11.05 07:37
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Думаю, что вполне возможно. Т.к. assert во время отладки удаляет все обращения по неверному индексу. В релизе, с большой вероятностью, все вызовы инлайнятся, а assert изымается, поэтому лишнего оверхеда нет.

Вот тут не понял. Куда изымется второе косвенное обращение? Мы же должны сначала обратиться по адресу imap+idx+2, и прибавить полученное смещение к nodes. При этом nodes лежат очень далеко от imap, потому что они в хипе, а imap — в сегменте данных.
E>А в твоем варианте взятие остатка от деления будет всегда.
Взятие остатка от деления выполняется в регистре, т.е. со скоростью процессора. Без тестирования я совершенно не уверен, кто тут будет быстрее и насколько.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.11.05 10:21
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

E>>Думаю, что вполне возможно. Т.к. assert во время отладки удаляет все обращения по неверному индексу. В релизе, с большой вероятностью, все вызовы инлайнятся, а assert изымается, поэтому лишнего оверхеда нет.

S>Вот тут не понял. Куда изымется второе косвенное обращение? Мы же должны сначала обратиться по адресу imap+idx+2, и прибавить полученное смещение к nodes. При этом nodes лежат очень далеко от imap, потому что они в хипе, а imap — в сегменте данных.

Это при эпизодических обращениях к imap будет справедливо. А если идет пакетная обработка/расчет, когда nodes дергаются постоянно, то imap закешируется.

E>>А в твоем варианте взятие остатка от деления будет всегда.

S>Взятие остатка от деления выполняется в регистре, т.е. со скоростью процессора. Без тестирования я совершенно не уверен, кто тут будет быстрее и насколько.

Так и я не утверждал ничего. Просто сказал, что вполне возможно.
Для своей машины, возможно, угадал: Re[21]: С++ culture
Автор: eao197
Дата: 11.11.05
.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: why off?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 11.11.05 10:33
Оценка: +1
Здравствуйте, c-smile, Вы писали:

CS>Глашатай .Net: От пристал... у нея там думатель унутре. Понял?! И вообще речь не о том!

CS>Главное что порог вхождения низкий...
CS>он: Хм... а я уже здесь как бы. Мне выйти и зайти?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 12.11.05 07:42
Оценка: +1
Здравствуйте, VladD2, Вы писали:

E>>Каких предположений и какой неверности? (см. Re[21]: С++ culture
Автор: eao197
Дата: 11.11.05
)


Ш>>>>>Так что что тут будет быстрее без исследования вопроса сказать сложно.


E>>>>Это точно.


VD>Или ты что-то другое имел в виду?


Именно это
Так ведь я не только согласился, что нужно поисследовать. А еще и поисследовал.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.11.05 15:46
Оценка: :)
Здравствуйте, GU Glez, Вы писали:

GG>Ага. Только, как всегда для совместимости свехру вниз введут еще столько новых уровней API и новых технологий с разными уровнями абстракции.


А зачем? Это же новая эксперементальная ОС. Тут скорее будет другая проблема. ОС просто не пойдет в коммерческий оборот еще лет 5-10.

GG> А для успокоения "неугодных" и "неправильно" мыслящих заплатят PR-щикам пару десятком мильонов, чтобы те переубедили "неугодных" и показали им, как все будет хорошо потом, когда привыкнешь


А тут я скорее с ними соглашусь. "Неправильно мыслящие" это действительно проблема. Концепция которую может развивать одна копрпорация может быть только одна. А разброд и шатания приведут только к ненужным прыжкам и сменам концепций.

Всегда найдутся люди которы, к примеру, не понравятся ХМЛ-ные теги и которые начнут агетировать за некую экзотику. MS же, с San-ом и IBM-ом стараются следовать стандартам и продивагать технологически и научные разработки в массы. И крикуны тянущие повозку в разные стороны тут только мешают.

Они конечно думаю, что только их мысли являются правильными. Вот только это их личные проблемы. Пусть сами свои мысли в жизнь и воплощают.

Народ же к сожелению не может четко определить перспективные технологии от крикунских. И PR тут становится самым простым способом убеждения. Люди по умнее фильруют PR и улавливают суть.

Собственно "крикуны" — это тоже PR.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: С++ culture
От: vdimas Россия  
Дата: 15.11.05 09:59
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Cyberax, Вы писали:


C>>И ну. Достает писать try..finally/using блоки в C#/Java, а в С++ я про

C>>них уже забыл.

VD>Можно по подробнее о проблемах с написанием using-га?


Проблемы скорее оформительского плана:
using (MyRAII1 r1 = new MyRAII1())
    using (MyRAII2 r2 = new MyRAII2())
        using (MyRAII3 r3 = new MyRAII3()) 
            using (MyRAII4 r4 = new MyRAII4()) {
                ...
                ...
            }

Даже в таком написании глаз не то чтобы радовал...
Однако, в некоторых конторах требуют, чтобы многострочные вложения ограничивались скобками, и тут уже вовсе дискотека:
using (MyRAII1 r1 = new MyRAII1())
{
    using (MyRAII2 r2 = new MyRAII2())
    {
        using (MyRAII3 r3 = new MyRAII3()) 
        {
            using (MyRAII4 r4 = new MyRAII4()) 
            {
                ...
                ...
            } 
        }
    }
}


бррр
Re[10]: С++ culture
От: vdimas Россия  
Дата: 15.11.05 19:40
Оценка: -1
Здравствуйте, Lazy Cjow Rhrr, Вы писали:


LCR>А что собственно "бррр"? И тем более чем не угодил первый вариант? И наконец, может есть третий вариант, который лучше их обоих?


В синтаксисе using не учтена возможность использования нескольких ресурсов на одном и том же уровне вложенности. И, если честно, то мне даже трудно представить себе последовательность раскрутки стека, даже в случае наличия такого синтаксиса, если при создании одного из ресурсов произошла исключительная ситуация. Эту ситуацию в C# описывают ручками и городят уровни вложенности там, где логически они не нужны.
Re[9]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.11.05 00:41
Оценка: +1
Здравствуйте, vdimas, Вы писали:

V>Проблемы скорее оформительского плана:

V>
V>using (MyRAII1 r1 = new MyRAII1())
V>    using (MyRAII2 r2 = new MyRAII2())
V>        using (MyRAII3 r3 = new MyRAII3()) 
V>            using (MyRAII4 r4 = new MyRAII4()) {
V>                ...
V>                ...
V>            }
V>

V>Даже в таком написании глаз не то чтобы радовал...

Ты бы хоть ради хомхмы прежде чем излагать свои теории на людях зашел бы в студию и попробовал написать этот код в ней. Она бы тебе сразу отформатировала код следующим образом:
using (MyRAII1 r1 = new MyRAII1())
using (MyRAII2 r2 = new MyRAII2())
using (MyRAII3 r3 = new MyRAII3()) 
using (MyRAII4 r4 = new MyRAII4())
{
    ...
    ...
}

И никаких проблем.

Собственно налог на плюсах будет примерно такой:
{
    MyRAII1 r1 = MyRAII1();
    MyRAII2 r2 = MyRAII2();
    MyRAII3 r3 = MyRAII3();
    MyRAII4 r4 = MyRAII4();
    {
        ...
        ...
    }
}
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: С++ culture
От: vdimas Россия  
Дата: 16.11.05 14:00
Оценка: -1
Здравствуйте, VladD2, Вы писали:

VD>А какая разница? Я не призивал использовать Сингулярити для создания копрпоротивных веб-порталов. Я просто заметил, что есть таки вполне разумные люди — ученые, которые пишут драйверы на C#. Пускай это пока что игрушка ученых, но идея эта уже далеко не бредовая.


Не ученых, а инженеров. Да, кстати, чем, по твоему, драйвер отличается от обычной программы? (раз их разработку на C# могут делать только ученые )

Я могу ответить — чем. Непосредственным обращением к аппаратуре. Что есть непосредственное обращение к аппаратуре? Это запись/чтение в память, общение с портами ввода/вывода (что можно рассматривать как частный случай обращения к немного другой памяти), а так же реакция на прерывания.

Может программа на C# непосредственно обращаться к портам ввода/вывода? или по фиксированным адресам памяти? Или настраивать внутренние регистры процессора на новые карты отображения виртуальных устройств ввода/вывода? НЕТ. И никогда не сможет by design. Очевидно, надо на ASM/C/C++ написать требуемый функционал, и приподнести его "на блюдечке" управляемой среде в виде простых интерфейсов. Реально это? Вполне. Разработка "научная"? гх-гхх

здесь:
http://www.rsdn.ru/Forum/Message.aspx?mid=1489998&amp;only=1
Автор: vdimas
Дата: 16.11.05
Re[16]: why off?
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.11.05 16:27
Оценка: :)
Здравствуйте, kliff, Вы писали:

K>Тебя наверное сильно задел такой фанатик)


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

K> Кстати ты чем-то похож на него, без обид только.


Я надеюсь, что это только поверхностная схожесть, так как свой выбор делаю на базе фактов, а не на базе мифов и аутотренинга.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: С++ culture
От: vdimas Россия  
Дата: 16.11.05 17:36
Оценка: +1
Здравствуйте, VladD2, Вы писали:

V>>Не ученых, а инженеров.


VD>У тебя уже пунктик на инженерах выработался.


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

VD>Именно ученых. Я бы даже сказал исследователях.


Да, и что исследуем? Вроде же можно пойти почитать про микроядерную архитектуру? Любой экперимент — априори исследование. Дык, я тогда тоже ученый. Где гипотезы, выкладки, расчеты и доказательства? Нету? то-то и оно... Доказывать нечего, надо "брать и делать". Инженерная разработка чистой воды.


VD>По-моему вопрос кто и что делает для этой ОС очевиден и обсуждения не требует.


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


VD>Почитай про микроядерную архитектуру. Глядишь твое мнение о том, что должен делать драйвер и изменится.


А если нет? Или существует только микроядерная архитектура?

VD>Задача драйвера устройсва — взаимодействовать с устройством на низком уровне обеспечивая высокоуровневый протокол для ОС и прикладных программ. При этом нет реальной необходимости непосредственно обращаться к аппаратуре и делать все остальное перечисленное тобой. Все обращения к портам и т.п. можно скрыть за очень небольшим по объему HAL-ом который будет выглядеть для драйвера как некое универсальное АПИ.


Это ты споришь или соглашаешься? вот из моего предыдущего поста:

VD>Очевидно, надо на ASM/C/C++ написать требуемый функционал, и приподнести его "на блюдечке" управляемой среде в виде простых интерфейсов.


Понимаешь, HAL она такая штука, что ее границы можно выбирать произвольно. Если сделать высокий уровень абстракций, то львиная доля кода перекочует в тот самый unmanaged, и блоки HAL под конкретные модели конкретных железяк в все так же будут разрабатывать вне C#.

Поэтому понятие "драйвер на C#" требует нового осмысления .

VD>Что же касается о невозможности обращаться к адресам памяти на C#, то это скорее говорит о товем знании C# нежели о его ограничениях.


Если ты про unsafe, то они же ведь собрались его постепено выкинуть, именно начиная с этой ОС, т.к. необходимость пропадет. И к портам все-равно невозможно обращаться. А при наличии HAL — и к памяти можно не обращаться.

V>>Может программа на C# непосредственно обращаться к портам ввода/вывода? или по фиксированным адресам памяти? Или настраивать внутренние регистры процессора на новые карты отображения виртуальных устройств ввода/вывода? НЕТ. И никогда не сможет by design. Реально это? Вполне. Разработка "научная"? гх-гхх


VD>По твоим словам получается разработчики Сингулярити нагло врут утверждая, что драйверы устройств написаны на C# без использования опасного кода. Но я почему-то скронен верить именно им, а не тебе.


Блин, я же сам в том посте и предположил, как именно это сделано. Это все и так понятно, в общем мимо.
Речь о том, что когда начнут вставлять реальные железки в реальные компы, то часть имплементации HAL возможно придется писать производителям железок. И не на C#.

VD>Что касается научности, то опять таки мнение гордого инжинера тут вряд ли окажется весомым. Цели исследований описаны на сайте проекта. То что эти цели счтены научными сомнений не вызвает, так как занимаются этим люди из университетов.


У них университеты частенько инженерные.
Да, именно, целые университеты занимаются инженерными разработками. Не накладывай совковую модель институтов на них, они сильно отличаются.

И всем плевать на мнение или там несогласие мое или твое. Есть довольно ощутимые границы научной и инженерной деятельности.

Научная:
    определения и аксиомы;
    теоремы;
    доказательства;
    интерпретация результатов.


Инженерная:

    определение требований;
    написание спецификаций;
    разработку и реализацию;.
    тестирование и анализ.


VD>Ты же, как всегда, с целью облить что-то неугодное тебе грязью выцепляшь из контекста какие-то одтельные веши и пыташся их "разоблочить". Зачем? Я не знаю. Но цедь явно не добрая.


я плакаль... И почему я не позволяю себе подобных высказываний в адрес оппонента? На любой твой выпад можно отвечать этими словами. Специально сохранил в "избранном" линк сюда.

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


VD>В общем, почитай про миноядерную архитектуру и идею HAL. Тогда возможно разговор на эту тему у нас и получится.


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

(Согласись, твои отсылки "пойти почитать, только тогда снизойду" на грани оффтопа, как и мой ответ )

Разговор не поэтому не получается, а из-за слишком сильной приверженности кого-то определенным взглядам, из-за очень легкого закрывания глаз на "неугодные" моменты и выпячивания других. Мы, в отличие от, спустимся медленно, медленно... И посмотрим внимательно, внимательно.
Re[19]: С++ culture
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.11.05 04:44
Оценка: +1
Здравствуйте, vdimas, Вы писали:


V>Понимаешь, HAL она такая штука, что ее границы можно выбирать произвольно. Если сделать высокий уровень абстракций, то львиная доля кода перекочует в тот самый unmanaged, и блоки HAL под конкретные модели конкретных железяк в все так же будут разрабатывать вне C#.

А зачем, собственно, произвольно выбирать ее границы? Есть довольно-таки простой критерий их выбора: надо предоставить доступ ко всему при минимальном объеме кода.

V>Речь о том, что когда начнут вставлять реальные железки в реальные компы, то часть имплементации HAL возможно придется писать производителям железок. И не на C#.


Может, я чего-то не понимаю? Дело в том, что с точки зрения 86й архитектуры есть, в общем-то, ровно две абстракции: память и порты. Все. Точка. Невозможно сделать железку, которая будет работать как-то по другому. Просто потому, что процессор ни до чего другого не сможет добраться. Все железки программируются именно так. Это означает, что достаточно сделать интринсик-функции чтения/записи в порт — и всё. Остальная логика программируется через них.

Развей, пожалуйста, мои заблуждения.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: С++ culture
От: vdimas Россия  
Дата: 18.11.05 17:21
Оценка: +1
Здравствуйте, mrozov, Вы писали:

M>Но я, честно говоря, не очень понимаю, как это мы ловко перескочили на java? При чем тут она? Java — рулит, но какое это имеет отношение к предмету разговора?


Я тебе говорил про накопленный багаж инструментария для разработки. Уходя в .Net мы оказываемся на довольно-таки голом месте. Я тебе показываю пальцем на Java (из одной весовой категории же), и говорю "хочу так же!!!".

Джаву не люблю, но разнообразию и качеству инструментов должен отдать должное. Взять тот же Эклипс с его бесплатными сотнями прибамбасов от UML до поддержки высокоуровневых вещей, типа struts и spring. Ты наверно не обратил внимание на эти 2 названия, а они весьма сильнозвучащие. Это такие технологии лепки сложных систем на-лету. Мизинцем левой ноги. На .Net все еще предстоит трахаться ручками и самостоятельно и довольно-таки много, ибо, кроме платформы практически ничего больше нет.

Никто не собирается обсуждать Java vs C#. Априори, базовая платформа .Net мощнее (не берусь утверждать насчет сравнения с 1.5). Но на этом пока все. С прикладными наработками ой как туго. Я просто чуствую себя в каменном веке, по сравнению с Java-программистом по уровню организации труда. Это тем более неприятно, что инструмент потенциально более мощный.

А с чего ветка-то началась?.. А, ну да, есть ли смысл переходить на дотнет ВСЕМ прямо сейчас...
Re[15]: off
От: mrozov  
Дата: 18.11.05 18:44
Оценка: :)
Коллеги, я верю в MS. Гораздо больше, чем во всех других производителей ПО вместе взятых. Пока эта вера меня не подводила.

За весь RSDN ответить не берусь.

Но! Разобравшись с .net, я пожалел, что не взялся за java в 2000 г. Однако, сейчас (и даже год назад) .net считаю лучшей ставкой. Но так как технологии близкие, то и веских аргументов (более веских, чем масса MS) у меня нет.

Примерно так. Но только топик вроде не об этом. все-таки.
Re[17]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.12.05 16:36
Оценка: -1
Здравствуйте, rombeck, Вы писали:

R>Ну если существуют ОС, полностью написанные на Java (JavaOS) и на Обероне, почему бы и не существовать ОС, полностью написанной на C#?


ОС полностью написанной на Яве не существует. На Обероне существует. Однако даже если бы всего этого небыло лично я не вижу препятсвий к созданию такой ОС.

R>А вот будет ли эта ОС развиваться и практически применяться — вопрос другой...


Эта? Нет конечно. Это всего лишь прототип. Просто возможно лет через 5-10 на базе полученной в этом ислледовании информации будет создана ОС нового поколения.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: С++ culture
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.12.05 19:14
Оценка: +1
Это не будет работать.

PC>Согласно ECMA 334 (15.13).


согласно данному пункту внутри using-а возможно только одиночное объявление типа, а не множественное (как в данном примере, с 4 разными типами)
Re[28]: С++ culture
От: Pzz Россия https://github.com/alexpevzner
Дата: 08.01.06 22:04
Оценка: :)
VladD2 wrote:
>
> V>Тебе описали реальную ситуацию, при которой виртуальные 2 гига набиты
> под завязку. Я охотно соглашусь лишь с тем, что у тебя лично ситуация
> обстоит по другому.
>
> ЖЦ и виртуальная память плохо дружат. Дело в том, что сборка мусора
> поднимит все данные в память, и если физической памяти не хватает, то
> начнется кольцивой свопинг, так что для ОС основанной на ЖЦ вопрос с
> виртуальной памяти можно не рассматривать.

Ну, вообще-то, ничто не мешает держать управляющие структуры (для GC)
отдельно от блоков собственно памяти, доступных приложению. В таком
случае, GC вовсе не обязано вызывать интенсивный свопинг.
Posted via RSDN NNTP Server 2.0
Re[30]: С++ culture
От: Pzz Россия https://github.com/alexpevzner
Дата: 09.01.06 00:22
Оценка: :)
VladD2 wrote:
>
> Pzz>Ну, вообще-то, ничто не мешает держать управляющие структуры (для GC)
> Pzz>отдельно от блоков собственно памяти, доступных приложению. В таком
> Pzz>случае, GC вовсе не обязано вызывать интенсивный свопинг.
>
> "Управляющие структуры" хранятся внутри каждого объекта.
>
> Дело в том, что даже банальный алогоритм определения достижимого графа
> объектов требует помечать найденные объекты. Да и сам перебор ведется
> непосредственно по самим объектам. Нельзя же хнанить отдельно поля объекта?

Чтобы помечать объекты, нужен флаг. Что мешает хранить эти флаги в
отдельной кучке?
Posted via RSDN NNTP Server 2.0
Re[15]: why off?
От: Plague Россия  
Дата: 01.04.08 08:57
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>

- Вот все говорят о дотнете, а ведь это полная туфта. На нем же даже игрушку написать нельзя.
VD>- Помилуйте, вот игршка. Загрузите, поглядите.

Например?
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[17]: why off?
От: CreatorCray  
Дата: 01.04.08 11:20
Оценка: +1
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>http://www.codeproject.com/KB/mcpp/quake2.aspx


Чтобы скомпилить уже готовое под managed C++ много ума не надо
Скорость работы — отвратительная.
Проект, который сразу бы под managed писался привести можете?

В свою очередь могу подсказать: CellFactor
Скачайте, посмотрите.
Разумеется есть вероятность, что в дичайших тормозах и неумеренном потреблении памяти виноваты кривые руки разработчиков а не .NET
Но факт остается фактом. Есть managed игра и она дико тормозит.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[2]: С++ culture
От: Ligen Украина http://zone-of-ambiguity.blogspot.com/
Дата: 19.10.05 14:22
Оценка:
Здравствуйте, aik, Вы писали:

aik>Это где так удачно аську разместил? Можно в мыло


хе-хе ))
на заборе, оччень известном, прям в центре города
дык, высылай, твою тож рядом напишу
Viva el Junta Militar! Viva el Presidente!
Re[2]: С++ culture
От: Ligen Украина http://zone-of-ambiguity.blogspot.com/
Дата: 19.10.05 14:24
Оценка:
Здравствуйте, Kisloid, Вы писали:

K>- главное чтобы мы никому не достались...


Ничего, как раз будет стимул заниматься физ подготовкой, так сказать, укреплять физическую немощь ))
Viva el Junta Militar! Viva el Presidente!
Re[3]: С++ culture
От: aik Австралия  
Дата: 19.10.05 14:24
Оценка:
Здравствуйте, Ligen, Вы писали:

aik>>Это где так удачно аську разместил? Можно в мыло

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

я свою аську не скрываю, она в каждом письме
Re[4]: С++ culture
От: Ligen Украина http://zone-of-ambiguity.blogspot.com/
Дата: 19.10.05 14:31
Оценка:
Здравствуйте, aik, Вы писали:

aik>я свою аську не скрываю, она в каждом письме


Ok.
Буду идти с работы, нарисую.
Time New Roman'ом. Или лучше в 3D ))
Жди толпы алчущих работодателей с горящими глазами
Viva el Junta Militar! Viva el Presidente!
Re[7]: С++ culture
От: Дарней Россия  
Дата: 20.10.05 10:39
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>И ну. Достает писать try..finally/using блоки в C#/Java, а в С++ я про


Меня больше достает отсутствие множественного наследования и константных ссылок.
а RAII на самом деле не так уж часто необходим
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re: С++ culture
От: DJ KARIES Россия  
Дата: 21.10.05 15:40
Оценка:
Здравствуйте, Ligen, Вы писали:

L>Выводы?

L>Есть такой анекдот в виде тоста:
L>"- Пусть представителей сексуальных меньшинств станет больше!!
L> — ???!!
L> — нам достанется больше женщин! "

Это истинно, если педиков будет больше.
А вот лесбийские девицы всё как раз и портят.

Так что, господа, да здравствует педерастия!
Ибо: "- нам достанется больше женщин!"
и множественного наследования в особо извращённой форме
http://likos.ru http://dkdens.narod.ru http://giref.forthworks.com
Re[5]: С++ culture
От: srggal Украина  
Дата: 21.10.05 18:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Это-то фигня. Больше всего раздражает, что GC уничтожает память

C>недетерминировано. А значит RAII и подобные идиомы не проходят.

Было и такое на СШарп:
Через Корбу использовались ValueType, причем их было много, во время работы ПО зажирало ~600метров, причем львиная доля этой памяти была ненужна после обработкуи вызова ( уходило все на клиента), но память освобождалась только после сборки мусора, которая происходила не часто. В свою очередь инициация сборки мусора приводила к загрузке системы, и проседало время реакции на запросы других клиентов.

Вот оно как бывает, и так больно, и так нехорошо

ЗЫ
Нормально Развалить ВалуеТипы — так и не смогли, если есть методы скажите
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[3]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.05 00:50
Оценка:
Здравствуйте, Ligen, Вы писали:

aik>>Это где так удачно аську разместил? Можно в мыло


L>хе-хе ))

L>на заборе, оччень известном, прям в центре города
L>дык, высылай, твою тож рядом напишу

А ЛДПР куда дел?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.05 00:50
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>И ну. Достает писать try..finally/using блоки в C#/Java, а в С++ я про

C>них уже забыл.

Можно по подробнее о проблемах с написанием using-га?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.05 00:50
Оценка:
Здравствуйте, Kisloid, Вы писали:

K>Кстати мня тоже это не радует, интересно, а почему бы просто не добавить плюс к управляемому хипу еще и неуправляемый ??? В таком случае я уже давно бы про С++ забыл бы...


А нахрина нужно в каменный век то возвращаться?

Ну, если уж очень хочется, то в ансэйве можешь использовать неуправляемый хип. К RAII это правда отношения не имеет. Но если надо...
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.05 00:55
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>более высокая стоимость в C++ ошибок других


А свои что бесплатные? Или все кто пишут на С++ сразу автоматом получают манию величия в форме веры в свою непогрешимость?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: С++ culture
От: Pavel Dvorkin Россия  
Дата: 03.11.05 06:53
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>И хотя я могу показаться крамольным... Тем не менее, следует учитывать, что язык в немалой степени определяет способ мышления. Хотя, если задача, или ещё какие-либо условия мышления не требуют, то спору нет, в таком контексте бессмысленно говорить о различиях языков, API и прочих подобных вещей.


+1

ГВ>А кто бы спорил?!


Да ведь спорят. Я в свое время мир предложил

http://www.rsdn.ru/Forum/Message.aspx?mid=1445599&amp;only=1
Автор: Pavel Dvorkin
Дата: 20.10.05


Не получается мир.
With best regards
Pavel Dvorkin
Re[4]: С++ culture
От: _Winnie Россия C++.freerun
Дата: 03.11.05 07:00
Оценка:
Здравствуйте, sch, Вы писали:

sch>GC из .NET -- не ужасен, просто он несколько другой. Именно это и пугает.


+1.
Кстати, malloc тоже не подарок в смысле предсказуемости по времени.
Но как мне не хватает RAII...
Правильно работающая программа — просто частный случай Undefined Behavior
Re[6]: С++ culture
От: Cyberax Марс  
Дата: 03.11.05 10:21
Оценка:
VladD2 wrote:

> C>Это-то фигня. Больше всего раздражает, что GC уничтожает память

> C>недетерминировано. А значит RAII и подобные идиомы не проходят.
> Нда, невежество в вопросах ЖЦ просто порожает. Ну, откуда ты взял, что
> ЖЦ уничтожает память? И чем тебе не угодил using?

Хорошо, не "уничтожает", а "передвигает выжившие объекты в начало кучи".
С терминологией я промахнулся, но думал, что смысл будет понятен.

> Действительно. Как может пугать то о чем даже понятия не имешь?


Ну-ну...

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[9]: С++ culture
От: GlebZ Россия  
Дата: 03.11.05 16:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>0. Его можно забыть.

Можно. GC все равно счистит. Слава GC.
C>1. using для ресурсов, хранящихся в полях класса уже не поможет.
Почему? Поможет. Во-первых, такие ресурсы стараются освободить как только можно быстрее, и они никак не становятся полями. Ну а во вторых делают Disposable не поля, а классы. И там уже вызывают все классы которые нужно сдиспоузить.

Вобщем, для любого языка важно сначала научиться готовить.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: С++ culture
От: Cyberax Марс  
Дата: 03.11.05 16:47
Оценка:
GlebZ wrote:

> C>0. Его можно забыть.

> Можно. GC все равно счистит. Слава GC.

Я бы за такое убивал нафиг. Один раз довелось поотлаживать приложение,
падающее при больших нагрузках — не закрывались коннекты к SAP (точнее,
закрывались в финализаторе) и его начинало глючить. Причем под отладкой
или без нагрузки все работало.

> C>1. using для ресурсов, хранящихся в полях класса уже не поможет.

> Почему? Поможет. Во-первых, такие ресурсы стараются освободить как
> только можно быстрее, и они никак не становятся полями.

Ну-ну. Все операции с коннектом к БД у вас делаются в одном методе?

> Ну а во вторых делают Disposable не поля, а классы. И там уже вызывают

> все классы которые нужно сдиспоузить.

Ну да, если в классе есть disposable-поле, то и сам класс нужно тоже
делать disposable. А затем класс, в котором он содержится и т.д.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[11]: С++ culture
От: GlebZ Россия  
Дата: 03.11.05 17:14
Оценка:
Здравствуйте, Cyberax, Вы писали:


C>Ну-ну. Все операции с коннектом к БД у вас делаются в одном методе?

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

C>Ну да, если в классе есть disposable-поле, то и сам класс нужно тоже

C>делать disposable. А затем класс, в котором он содержится и т.д.
Тебе понравилось? Здоровски да? Мне тоже нравится. Но этого мало. В подобных Dispose/finalize много своих особенностей. Их нужно знать и выполнять.(собственно как и особенности в С++). Одно только радует, такие вещи делаются очень редко.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.05 18:00
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Можно по подробнее о проблемах с написанием using-га?


C>0. Его можно забыть.


Хм. А использовать смарт-поинтер забыть нельзя?

C>1. using для ресурсов, хранящихся в полях класса уже не поможет.


Вообще-то если ты не контролируешь память, то хнинить что-то из ресурсов в полях обычно не приходится. Хотя и для этого случая есть Dispose().
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.05 18:00
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>VladD2 wrote:


>> C>Это-то фигня. Больше всего раздражает, что GC уничтожает память

>> C>недетерминировано. А значит RAII и подобные идиомы не проходят.
>> Нда, невежество в вопросах ЖЦ просто порожает. Ну, откуда ты взял, что
>> ЖЦ уничтожает память? И чем тебе не угодил using?

C>Хорошо, не "уничтожает", а "передвигает выжившие объекты в начало кучи".


С этим ты тоже промахивашся. Дело в том, что 99% объектов умирают в нулевом и первом поколении. При этом они никуда не предвигаются. А выживших объектов крайне мало и они копируются в старшую кучу. Только второе поколение дефрагментируется. И происходит это крайне редко.

Например, сейчас глянул сколько сборок мусора было произведено в Янусе за время прощедшее с его последнего перезапуска. Оказалось 308. Перезапускал же я его в последний раз 17 с чем-то часов... 30.10.2005. То есть Янус делал меньше 100 сборок мусора в день. А использую я его довольно плотно.

C>С терминологией я промахнулся, но думал, что смысл будет понятен.


Твоя мысль понятна. Но судишь ты о мало тебе знакомой проблеме. Вообще странная ситуация. Все кто пользуется дотнетом не находят проблем в описаваемых теоретиками случаях. Но теоретики от этго не унимаются. Все равно спорят. Неужели так сложно попробовать написать пару приложений? Глядишь понравится и...

>> Действительно. Как может пугать то о чем даже понятия не имешь?


C>Ну-ну...


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

Эти вопросы сто раз обсуждались. И на них давались исчерпывающие ответы. Но просто кому-то чень хочется верить в свои фобии.

Остается вопрос — зечем?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: С++ culture
От: Cyberax Марс  
Дата: 03.11.05 18:12
Оценка:
VladD2 wrote:

> C>0. Его можно забыть.

> Хм. А использовать смарт-поинтер забыть нельзя?

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

> C>1. using для ресурсов, хранящихся в полях класса уже не поможет.

> Вообще-то если ты не контролируешь память, то хнинить что-то из
> ресурсов в полях обычно не приходится. Хотя и для этого случая есть
> Dispose().

Ну-ну.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[8]: С++ culture
От: Cyberax Марс  
Дата: 03.11.05 18:19
Оценка:
VladD2 wrote:

> C>Хорошо, не "уничтожает", а "передвигает выжившие объекты в начало

> кучи".
> С этим ты тоже промахивашся. Дело в том, что 99% объектов умирают в
> нулевом и первом поколении. При этом они никуда не предвигаются. А
> выживших объектов крайне мало и они копируются в старшую кучу.

Это и называется "передвигает выжившие объекты" (aka "promotes", "tenures").

> C>С терминологией я промахнулся, но думал, что смысл будет понятен.

> Твоя мысль понятна. Но судишь ты о мало тебе знакомой проблеме. Вообще
> странная ситуация. Все кто пользуется дотнетом не находят проблем в
> описаваемых теоретиками случаях.

Твоя мысль понятна. Но судишь ты о мало тебе знакомой проблеме. Вообще
странная ситуация. Все кто пользуется С++ не находят проблем в
описаваемых теоретиками случаях.

> А что "ну-ну"? Твои слова говорят об этом совершенно определенно. Да

> что уж там. Ты даже поиском не потрудился воспользоваться прежде чем
> взяться повторять эти догмы. Ты думашь, первый кто это говорит?

Если вы сомневаетесь в моих знаниях GC, то можете почитать этот топик,
например: http://rsdn.ru/Forum/Message.aspx?mid=995758&amp;only=1
Автор: Cyberax
Дата: 20.01.05


--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[6]: С++ culture
От: GU Glez  
Дата: 03.11.05 18:54
Оценка:
Здравствуйте, VladD2, Вы писали:

GG>> Меня всегда удивляет одно — где можно найти профессионального врача владеющего всеми (или очень многими) областями медицины?

VD>Хм. Наверно таких враченй называют педиаторами. Но к делу это вряд ли относится.
Подчеркиваю профессинальный врач, т.е. тот который понимает большинство аспектов данной области. Наверное нужно было для этого написать: "...найти профессионального врача владеющего профессионально всеми областями медицины...", но как-то язык не повернулся
GG>> Не помню кто сказал, но думаю это рядом с истиной: "Профессионал во всем — зовется дилетант". Хотя, с утверждением, что программирование — область в которой необходимо постоянно изучать и "мыслить как можно лучше", путем изучения нового — думаю согласятся многие.
VD>Вообще-то я вел речь не о глубоких знаниях всего насвете. Я говорил о ЯП. ЯП это нечто большее чем просто чем просто язык. Он определяет мироваозрение. С++-программист никогда не поймет Ява-, ВБ- или Смолток-программиста. Как, в прочем, и на оборот. Но если встречются два программисто знащих перечисленные языки, то ни будут прекрасно понимать друг-друга даже если в данный момент каждый из них использует отличный от другого язык.
+1
Теперь согласен
С уважением,
GU Glez [Джи Ю Глиз]
Re[9]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.05 21:13
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Твоя мысль понятна. Но судишь ты о мало тебе знакомой проблеме. Вообще

C>странная ситуация. Все кто пользуется С++ не находят проблем в
C>описаваемых теоретиками случаях.

Это было бы так если бы я лет 10 не писал на этом языке.

C>Если вы сомневаетесь в моих знаниях GC, то можете почитать этот топик,

C>например: http://rsdn.ru/Forum/Message.aspx?mid=995758&amp;only=1
Автор: Cyberax
Дата: 20.01.05


Я гляжу на слова. А слова явно странные.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.11.05 14:17
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

VD>>Речь не об абстрактном мыслительном поцессе. А о программировании где язык определяет мировозрение программиста. Мы мыслим на ЯП. Более мощьный язык позволяет описывать проблему более абстракно и просто.


ГВ>Э... а определение понятия мощности языка можно? Тут когда-то бодались уже по этому поводу, да я уж подзабыл, где именно. AFAIK, LISP тут впереди планеты всей.


Оно в цитате выше.

VD>>Мысля на одном языке программист невольно ограничивает свое мировозрение принятыми в нем паттернами.


ГВ>Зависит от степени, в которой язык навязывает такие ограничения.


Независит. Любой язык навязывает свои подходы.

ГВ> Например, Java навязывает использование GC и одиночного наследования.


ЖЦ наоборот снимает неободимость ручного управления памяти. Назвать это навязыванием мягко говоря неверно.

ГВ> Ибо иного не дано. Тогда как C++ этого не делает. Lisp, кстати, тоже, если не считать GC.


Что "Lisp, кстати, тоже"? Не навязывает ЖЦ если не считать того что лисп без ЖЦ вообще невозможен?

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

Чувствую, что происходит очередная попытка увести от темы.

VD>>Другие языки дают другие подходы. И может оказаться так, что более красивое решение очевидно для пользователя одного языка, но не очевидно для другого.


ГВ>Да, это может быть так, только вот связывать доступность решения с опытом использования того или иного языка неправомерно. Одно и тоже решение (скажем, замыкания) может быть описано и на Lisp, и для С# и в терминах object pascal, однако сути самого решения это не изменит. Равно как и его доступности, скажем, тому, кто знает паскаль, но не знает Lisp.


Запыкания Дельфи (так как в Паскале их никогда не было) довольно ограничены по возможностям и в купе с культурой языка не дают программисту знающему только один Дельфи полного понимания этой концепции. Более того, даже функции высшего порядка и те опускаются культурой языка. Так что обычно Дельфийцы и этих концепций толком не понимают. Для них замыкания — это способ реализовать события. Хотя вообще этот термин слишком сумбурен.

Так вот, я говорил о том, что Язык как бы накладывает фильтр на мировозрение пользователя. И зная только один язык, пусть даже самый необычный или полиглотный, человек все равно будет мыслить очень ограничено.

VD>>Зная несколько языков программист способен более трезво смотреть на проблему выбирая те подходы которые ниболее удобны в данном случае.


ГВ>Очень спорно. Здесь всё зависит не от языка, а от набора решений известных программисту


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

ГВ>и... я бы назвал это самостоятельностью мышления.


А оно просто не может быть полноценным если человек знает только один язык. Это, кстати, хорошо демонстрируют фанатики С++ или Оберона (которые чеще всего принципиально игнорируют альтернативу). Например, можно поглядеть как некоторые С++-ники воспевают метапрограммирование на шаблонах, даже не зная, что по сравнению с теми же макросами Лиспа оно является мягко говоря неудобным и недоделанным. Другой пример — оберонщики. С таким пылом рассказывать о компонентных возможностях языка в то время, как есть куда более интересные реализации.

ГВ> Да, кстати, я не спорю с тем, что полезно знать нескольких языков. Я просто считаю приведённую выше формулировку слишком поверхностной.


Это твои проблемы. Я и не брался давать формулировку для энциклопедии. Я выражаю свое мнение. Оно просто — программист знающий только один ЯП является очень ограниченным. Для того чтобы быть хорошим программистом нужно обязательно знать несколько языков и желательно концептуально разных. У нас есть следующие парадигмы: структурнрая, объектно ориентированная, компонентная, функциональная, метопрограммная (ничего не забыл?). Вот хотя бы под 2 языка поддерживающих каждую парадигму и нужно знать. Хотя бы в общих чертах.

VD>>Просто сам факт владения уже говорит о многом.


ГВ>Угу, например — о любопытстве.


И о нем в том числе. Программист без любопытства — это болван.

ГВ>Да видел я эту дискуссию. А потом, я разве говорил, что Java унаследована только от C++? Просто мне кажется, что Java заполучит аудиторию C/C++-программистов несколько легче и быстрее, чем, например, тех же Smalltalk-еров.


Почти согласен. Только нужно понять, что аудитории смолтокеров практически не существует в природе. Но то что синтаксическое сходство было в немалой степени направленно на аудиторию С/С++-ников я согласен. Вот только если взять тот же Шарп, и поглядеть кто на него переходит, то окажется, что С++-ников не такой уж и большой процент. Дельфистов и явщиков тут очень не мало.

Ну, да человек перешдший с другого языка уже знает два.

ГВ> А лёгкость сия связана с тем, что культура Java близка культуре C++ в силу того, что C++ есть в родителях Java.


Нет. Культуры как раз очень разные. Близкий только синтаксис. Все же Ява и С++ это языки исповедующие разные парадигмы. Ява компонентный и динамический язык с минималистическим синтаксисом, а С++ статический (не компонентный) и монструозный.

ГВ>Я и не говорю о 100% совпадении. Я апеллирую только к близости синтаксисов.


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

ГВ>Простейшие вещи, разумеется. Объявления переменных и констант, арифметика, операторы, вызовы функций.


Объявления — это синтаксис. А вот то что поля (переменные-члены типов) в С++ видны только вниз, а в Яве и Шарпе видны везде в том же пространстве имен — это уже семантика. И она явно разная. Причем очень сильно разная.

ГВ>Ну, если не забывать, что Дельфи через object pascal (и turbo pascal v.5.5+) тоже заполучила некоторую часть C++-культуры...


Боюсь, что у тебя болезнненное отньшение к С++. То что "заполучила" дельфи уже было во многих языках.

ГВ>Значит, добавим к исходному тезису утверждение, что на Java несложно перейти со Smalltalk.


Не сложнее чем с С++.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 06.11.05 14:30
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>> А лёгкость сия связана с тем, что культура Java близка культуре C++ в силу того, что C++ есть в родителях Java.


VD>Нет. Культуры как раз очень разные. Близкий только синтаксис. Все же Ява и С++ это языки исповедующие разные парадигмы. Ява компонентный и динамический язык с минималистическим синтаксисом, а С++ статический (не компонентный) и монструозный.


Влад, извини, что увожу тему в сторону, но почему ты считаешь Java динамическим языком?
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.11.05 00:39
Оценка:
Здравствуйте, eao197, Вы писали:

E>Влад, извини, что увожу тему в сторону, но почему ты считаешь Java динамическим языком?


Вообще-то его таковым считали авторы еще при создании.

А вообще, что тут считать то? Язык позволяет делать динамически все от загрузки объектов, до компиляции.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: С++ culture
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 07.11.05 04:23
Оценка:
Здравствуйте, VladD2, Вы писали:

[skip, ибо...]

ГВ>> Да, кстати, я не спорю с тем, что полезно знать нескольких языков. Я просто считаю приведённую выше формулировку слишком поверхностной.

VD>Это твои проблемы. Я и не брался давать формулировку для энциклопедии. Я выражаю свое мнение. Оно просто [...]

Тогда я прекращаю дискуссию.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[4]: С++ culture
От: ie Россия http://ziez.blogspot.com/
Дата: 07.11.05 04:51
Оценка:
sch>Как говорил один замечательный художник и просто умный человек: причиной любого конфликта является непонимание.

ИМХО, маленько не так: В конфликте не бывает абсолютно правых, бывает лишь общее непонимание.
Превратим окружающую нас среду в воскресенье.
Re[13]: С++ culture
От: sch  
Дата: 07.11.05 13:11
Оценка:
Здравствуйте, eao197, Вы писали:

E>И все это "из коробки" для любого метода и любого класса. Другой вопрос насколько это надо и когда это стоит использовать. Но делать вручную то же самое на C++ и тяжело и вряд ли необходимо.


Согласен с тобой по всем пунктам.

Тут просто действует общее правило, которое заключается в том, что на C++ можно делать *все*, только напильником поработать надо
Re[13]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.11.05 23:17
Оценка:
Здравствуйте, eao197, Вы писали:

E>Здравствуйте, VladD2, Вы писали:


E>>>Можно ли в Java вводить новые методы в уже существующие классы?


VD>>Да. На том построена туча фрэймворков.


E>Каких?


А на строчку ниже взглянуть слабо было?

VD>>Опять же да. Если бы это было невозможно, то разных Spring-ов просто не существовало бы.


Или влом было погуглить?

http://www.optim.ru/cs/2004/3/spring/spring.asp
Spring в гугле

E>Может быть на уровне манипуляций с байт-кодом Java и можно что-либо подобное делать, но к языку Java это оношения уже не будет иметь.


Ну, конечно. А к чему интересно имеет? Спринги и т.п. как раз так и устроены. Они дают декларативный интерфейс к динамическим возможностям среды. А в основе лежат рефлексия, кодогенерация и динамическое создание экземляров.

E>Кстати, а в C# возможно добавление/изъятие методов в класс, после того, как класс уже будет полностью определен?


Несколькими способами. От RealProxy до эмита.

Вот только ты почему-то считашь, что динамичность языка определяется добавлением кода в рантайме. Как раз это нужно довольно редко. А вот создать и проинциализировать объект основываясь только на его описании полученном в рантайме — это задача очень частая. В плюсах без создания специального фрэймворка (или использования разных КОМ-ом) не решаемая.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: С++ culture
От: Stoune  
Дата: 08.11.05 03:29
Оценка:
Здравствуйте, aik, Вы писали:


aik>Это где так удачно аську разместил? Можно в мыло

Так надо заполнить поля в своей аське, у меня в интересах С++, так на меня сами из большого кадрового агенства через поиск нашли, жаль я уже на тот момент выбрал свой путь, а предложение было очень соблазнительным.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re[11]: С++ culture
От: Kluev  
Дата: 08.11.05 13:41
Оценка:
Здравствуйте, mrozov, Вы писали:

K>>Есть такая отрасль CAD/CAE/CAM называется.


M>А еще есть отрасль под общим названием "прикладное программирование", в которой задействовано подавляющее большинство разработчиков.

А CAD — не прикладное программирование?

K>>Только исключений слишком много.

M>Я вижу очень мало. А я по меркам большинства моих коллег — хардкорщик.
Реальность это больше чем мы видим. А мерки вещь очень относительная. Для кого-то и VB-шник хардкорщик.

K>>
K>>class CSharpTriangle
K>>{
K>>  public Node[] nodes = new Node[3]; // все приехали, можете закрывать свою лавочку
K>>}
K>>


M>Контраргумент:

M>x = x + 1;

И в чем же аргумент? сам хоть понял что сказал?
Re[13]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.11.05 14:15
Оценка:
Здравствуйте, mrozov, Вы писали:

K>>А CAD — не прикладное программирование?


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

M>Вы знаете, сколько в мире программистов на VB/Delphi? Сколько web-программистов?

А интересно, сколько в мире Delphi программистов?

Вот C++ программистов, по озвученной Страуструпом оценке, около 3 миллионов. Неужели это можно назвать каплей в море?
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: С++ culture
От: mrozov  
Дата: 08.11.05 14:19
Оценка:
Здравствуйте, eao197, Вы писали:

E>Вот C++ программистов, по озвученной Страуструпом оценке, около 3 миллионов. Неужели это можно назвать каплей в море?


Я сам — с++ программист. И что?
Я бы поставил вопрос иначе — сколько в мире задач, для которых с++ будет оптимальным выбором?

До Java и широкого распространения web — подавляющее большинство.
После .net — очень и очень вряд ли.
Re[15]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.11.05 14:25
Оценка:
Здравствуйте, mrozov, Вы писали:

E>>Вот C++ программистов, по озвученной Страуструпом оценке, около 3 миллионов. Неужели это можно назвать каплей в море?


M>Я сам — с++ программист. И что?

M>Я бы поставил вопрос иначе — сколько в мире задач, для которых с++ будет оптимальным выбором?

Давай так: перечисли те прикладные области, которые ты знаешь. Так будет проще оценивать перспективность языка.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: С++ culture
От: Kluev  
Дата: 08.11.05 15:33
Оценка:
Здравствуйте, mrozov, Вы писали:

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

M>Вы знаете, сколько в мире программистов на VB/Delphi? Сколько web-программистов? Вы мне говорите о капле в море, которую пытаетесь возвести в закон. Понимания в моем лице, естественно, не добиваясь.

И что теперь? Меня мало беспокоит число пользователей языка, а больше интерсуют возможности и удобство. А по многим параметрам у С++ до сих пор нет никаких альтернатив, ни по удобству ни по скорости.

M>Отойдем чуть в сторону и что же мы видим? Ба, да это же Java-программисты! Которые Вам с удовольствием расскажут, насколько велика их доля рынка и насколько нелепо Вы будете смотреться, пытаясь написать application layer средненькой такой корпорации на с++.


Так же нелепо смотрятся и деятели которые говорят что java/net смогут заменить С++
Есть целое море задач для которых лучше чем С++ (пока) не найти.

K>>И в чем же аргумент? сам хоть понял что сказал?

M>Многоуважаемый коллега! Позволю себе переадресовать Вам Ваш же вопрос (раз уж мой не в меру тонкий намек остался непонятым).

В чем же тонкость намека непойму? О вполне конкретных вещах писалось, жирным шрифтом выделено.
Re[13]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.11.05 18:00
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

E>>>Можно ли в Java вводить новые методы в уже существующие классы?


VD>>Да. На том построена туча фрэймворков.


ANS>Кстати. Требуется помощь зала по жабке. Есть некий класс A.

ANS>Создадим его экземпляр так:

ANS>A a = new A() {public void newMethod() {/* do nothing */};};


ANS>Как можно вызвать этот новый метод не прибегая к рефлексии?


Хороший вопрос, однако. Может быть, на него кто-то и ответит.
Я бы хотел на другом остановиться. На самом деле здесь не модифицируется класс A, а порождается новый, анонимный класс (или как он в Java называется), производный от A.

Вот небольшой реальный тест.
Файл A.java:
class A
{
    public void hello() { System.out.println( "original hello!" ); }
}

Файл Test.java:
class Test
{
    private static void use( A a )
    {
        Class s = a.getClass().getSuperclass();
        System.out.println( "use object of: " + a.getClass().getName() +
            ", with superclass: " + s.getName() );

        a.hello();
    }

    public static void main( String args[] )
    {
        A a;
        use( a = new A() {
                public void bye() { say_bye(); }
                private void say_bye() { System.out.println( "bye!" ); }
            }
        );

        A b;
        use( b = new A() {
                public void hello() { System.out.println( "another hello!" ); bye(); }
                public void bye() { say_bye(); }
                private void say_bye() { System.out.println( "another bye!" ); }
            }
        );
    }
}


Если запустить, то получаем:
use object of: Test$1, with superclass: A
original hello!
use object of: Test$2, with superclass: A
another hello!
another bye!


Т.е. создаются новые классы Test$1 и Test$2, которые производные от A. Но, т.к. в программе они присваиваются ссылкам на экземпляры A, то вызывать из них напрямую можно методоы, определенные в A.

Другое дело, что объект, скажем класса Test$1, можно использовать в качестве шаблона для порождения аналогичных объектов (через getClass() и getConstructor()). Однако, определение Test$1 должно быть доступно в compile-time. С таким же успехом через кодогенерацию можно описать какой-нибудь C++ класс, производный он нужного нам класса, скомпилировать в DLL, подгрузить DLL в процесс и -- опа! Получаем то же самое. Почти.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: С++ culture
От: mrozov  
Дата: 09.11.05 10:36
Оценка:
Здравствуйте, Kluev, Вы писали:

K>И что теперь? Меня мало беспокоит число пользователей языка, а больше интерсуют возможности и удобство.


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

K>Так же нелепо смотрятся и деятели которые говорят что java/net смогут заменить С++

K>Есть целое море задач для которых лучше чем С++ (пока) не найти.

Море? Да ну? А может все-таки болото?
Шучу-шучу.

Просто лично я говорю не о тотальном уничтожении с++, а о постепенном, но неминуемом выдавливании его из массового использования.
Re[12]: С++ culture
От: GlebZ Россия  
Дата: 09.11.05 10:58
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Дотнетовский массив — это ссылочный тип который в GC-хипе аллоцируется.

Ну и что?
K>В NET нельзя сделать массив частью аггрегата, как в С++:
K>
K>struct Triangle
K>{
K>   Node  *nodes[3];
K>};
K>

А зачем указатели? Это оверхед.
K>В итоге имеем оверхед на ровном месте. В качестве примера цифры из реальной жизни.
K>В программе ~150000 обьектов в которых 8 фикс.массивов на борту, ~50000 в которых 15.
K>В С++ общее число обьектов: 200 тысяч.
K>В .NETе 150к + 150к*8 + 50к + 50к*15 = 2,150,000
Не понял расчеты, ну да ладно.
Поскольку node — структура(а я надеюсь от него наследоваться не надо), то в дотнет хранение массива по чтению не сильно отличается от сишного. Так что массив будет аналогичной конструкцией.
K>Если смысл обсуждать дальше? Конечно можно возразить (на примере того же треугольника) делай вот так и будет щастье:
K>
K>class Triangle
K>{
K>   public Node A, B, C; // вместо массива переменные
K>}
K>

K>Но это уже буллшит какой-то.
Ничего криминального не вижу. Это номальный учет особенностей среды.
K>В треугольнике, например, нужен именно массив, который для удобства еще и закольцовывается:
K>
K>Node* node_at( int idx )
K>{
K>   static const int imap[] = { 1, 2, 0, 1, 2, 0, 1 };
K>   return nodes[imap[idx+2]]; // транслируем колецевой индекс в обычный
K>}
K>// юзается очень удобно, пример вычисление всех углов:
K>void angles(Triangle &t)
K>{
K>   double angs[3];
K>   for ( int i = 0; i < 3; i++ )
K>      angs[i] = angle( t.node_at(i-1), t.node_at(i), t.node_at(i+1) );
    
K>}
K>

Легко делается аналогично.
K>И это элементарные вещи широко используемыые в повседневной жизни. В NET на таких простых вещах имеешь либо оверхед либо гемморой, а чаще и то и другое вместе взятое.
Нет, не в моей повседневной жизни. Просто в С++ значительно большее поле для игры с памятью. Но приведенный пример показательным не назовешь.

С уважением, Gleb.
ЗЫ. А все таки зафигом там указатели.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: С++ culture
От: Kisloid Мухосранск  
Дата: 09.11.05 11:19
Оценка:
Здравствуйте, Kluev, Вы писали:

K>>>Для примера достаточно одной таблетки — простой класс треугольник:

K>>>
K>>>class CSharpTriangle
K>>>{
K>>>  public Node[] nodes = new Node[3]; // все приехали, можете закрывать свою лавочку
K>>>}
K>>>

А что в этом такого ??? Я так понимаю что вы подумали при строчке "Node[] nodes = new Node[3];" создаются 3 объекта Node в памяти ? Ну так вот, это совсем не так.
Этот класс почти аналогичен вашему:
K>
K>struct Triangle
K>{
K>   Node  *nodes[3];
K>};
K>

K>В итоге имеем оверхед на ровном месте. В качестве примера цифры из реальной жизни.
K>В программе ~150000 обьектов в которых 8 фикс.массивов на борту, ~50000 в которых 15.
K>В С++ общее число обьектов: 200 тысяч.
K>В .NETе 150к + 150к*8 + 50к + 50к*15 = 2,150,000
ничего не понятно...

K>Если смысл обсуждать дальше? Конечно можно возразить (на примере того же треугольника) делай вот так и будет щастье:

K>
K>class Triangle
K>{
K>   public Node A, B, C; // вместо массива переменные
K>}
K>

K>Но это уже буллшит какой-то.
K>В треугольнике, например, нужен именно массив, который для удобства еще и закольцовывается:
K>
K>Node* node_at( int idx )
K>{
K>   static const int imap[] = { 1, 2, 0, 1, 2, 0, 1 };
K>   return nodes[imap[idx+2]]; // транслируем колецевой индекс в обычный
K>}
K>// юзается очень удобно, пример вычисление всех углов:
K>void angles(Triangle &t)
K>{
K>   double angs[3];
K>   for ( int i = 0; i < 3; i++ )
K>      angs[i] = angle( t.node_at(i-1), t.node_at(i), t.node_at(i+1) );
    
K>}
K>

Тоже самое легко можно на шарпе сделать
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Re[13]: С++ culture
От: Kluev  
Дата: 09.11.05 11:40
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Kluev, Вы писали:


K>>Дотнетовский массив — это ссылочный тип который в GC-хипе аллоцируется. В NET нельзя сделать массив частью аггрегата, как в С++:


AVK>
AVK>struct CSharpTriangle
AVK>{
AVK>  public fixed Node nodes[3];
AVK>}
AVK>


Это откуда дровишки? В VS2003 не работает
Re[18]: С++ culture
От: mrozov  
Дата: 09.11.05 11:42
Оценка:
Здравствуйте, eao197,

В общем-то, ни с чем из сказанного Вами я спорить не собираюсь. В смысле, я не совсем согласен, но придираться к словам не буду — в целом Вы абсолютно правы.
Re[14]: С++ culture
От: GlebZ Россия  
Дата: 09.11.05 11:45
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Один узел разделяется м-ду несколькими треугольниками. А из треугольников делается сетка. Поэтому и указатели.

K>Массив из трех указателей, на Node. Оверхед равен нулю.
Понятно.

K>Суть в том что сишные-фиксированные массивы не аллоцируются сами по себе в хипе, а входят в состав обьекта, и все распределяется одним махом. Дотнетовские массивы должны распределится отдельно, т.е. один аллок на обьект и + несколько на массивы. В итоге в С++ будет распределено 200к обьектов, а в NET-e почти в 11 раз больше. Чувствуешь разницу? Или память это не ресурс? Фактически GC прийдется регулярно обрабатывать больше 2 млн обьектов. И это только часть от big picture.

Честно говоря если бы данная задача стояла бы у меня под dotnet, я бы делал совсем по другому. Инстанцировалось бы только на момент операции, трианглы были immutable, и легко собирались бы в нулевом поколении. Конечно со стороны все кажется легко и решение за пять секунд — очень субьективно.


K>Ага, а обращение по индексам будем делать так?

K>
K>Node node_at( int idx )
K>{
K>   switch ( idx )
K>   {
K>      case 0: return A;
K>      case 1: return B;
K>      // понеслась 
K>   }
K>}
K>

K>И не кажется ли тебе такое программирование гемором?
Зачем, лучше так
Node next_node()
{
  yeald return A;
    yeald return B;
    yeald return C;
}


В сях такого нет.
С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: С++ culture
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.11.05 12:01
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Это откуда дровишки?


Это 2 фреймворк.
... << RSDN@Home 1.2.0 alpha rev. 617>>
AVK Blog
Re[8]: off
От: mrozov  
Дата: 09.11.05 12:13
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Спорить о вкусе устриц, как это не печально, можно только с теми, кто их ел.


Ну почему же? Спорить вообще можно с кем угодно и о чем угодно. Доказано интернетом

К примеру, недавно один комрад, лично со мной не знакомый, пытался меня убедить в том, что мне не больше 20 лет. Приводил исключительно интерестные аргументы, надо заметить.
Re[16]: С++ culture
От: GlebZ Россия  
Дата: 09.11.05 12:49
Оценка:
Здравствуйте, Kluev, Вы писали:

Честно говоря при нехватке памяти Dotnet ведет себя "мягко говоря" — не очень. Ему очень нравится когда есть излишек памяти. Поэтому задачи данного типа не для него.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.05 00:32
Оценка:
Здравствуйте, mrozov, Вы писали:

M>. Ни один разумный человек не станет убеждать окружающих в том, что драйвера нужно начинать писать на C#.


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

Откуда они? Из MS Research. Занимаются они разработкой уравляемой ОС.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: off
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.05 01:47
Оценка:
Здравствуйте, mrozov, Вы писали:

M>К примеру, недавно один комрад, лично со мной не знакомый, пытался меня убедить в том, что мне не больше 20 лет. Приводил исключительно интерестные аргументы, надо заметить.


Никак пытался оправдаться по поводу "почему его девки не любят"?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.05 03:03
Оценка:
Здравствуйте, mrozov, Вы писали:

M>Здравствуйте, Cyberax, Вы писали:


C>>Твоя мысль понятна. Но судишь ты о мало тебе знакомой проблеме. Вообще

C>>странная ситуация. Все кто пользуется С++ не находят проблем в
C>>описаваемых теоретиками случаях.

M>Наглая и беспринципная ложь, коллега!

M>

Полегче, плиз. Я конечно понимаю, что коллега оценивает знания других неправомерно, но все же.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: С++ culture
От: Кузнецов Денис Викторович Казахстан  
Дата: 10.11.05 08:12
Оценка:
Здравствуйте, VladD2, Вы писали:

M>>. Ни один разумный человек не станет убеждать окружающих в том, что драйвера нужно начинать писать на C#.


VD>Кстати, ты все же ошибашся. Есть таки очень разумные и весьма дальновидные люди которые пишут драйверы на C#. Правда, другим они пока это делать не предлагают, но когда-нибудь это обязательно произойдет.


VD>Откуда они? Из MS Research. Занимаются они разработкой уравляемой ОС.


Исследования, на то они и исследования, чтобы ошибаться. Причем часто. А реальная применимость где? Где скачать, установить и как реально можно использовать? Они хоть на бумаге могут писать эти драйвера. Это ж Research!!!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.05 15:50
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Могу кусок лога показать, посчитаем с точностью до байта, полегчает от этого?


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

...

K>Самому не смешно?


А что мне смеяться то?

K>А нужно всего-то:

K>
K>struct Triangle
K>{
K>   Node *nodes[3];
K>   Node* node_at( int idx ) // кольцевой доступ
K>   {
K>      static const int imap[] = { 1, 2, 0, 1, 2, 0, 1 };
K>      return nodes[imap[idx+2]];
K>   }
K>};
K>


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

Написать аналогичный по объему и безобразию код никаких проблем нет. Выкинь из примера все и оставь тольео индексатор. Получится тоже самое.

Код этот один фиг пишется один раз на проект. И жалеть тут 20 строк смысла нет. Лучше уж иметь более защищенную и удобную систему. А вот использование будет полностью идентично.

VD>>А можно применить ансэй и будет точно так же как на плюсах. Если при этом как следует инкапсулировать опасный код, то дальше можно работать совершенно безопасно.


K>А почему бы тогда сразу не на плюсах? Зачем какие-то танцы с бубном.


Потому что оптимизации требует отдельные, редко встречающиеся кусти кода, а безопасность и скорость разработки нужны везде.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.05 16:23
Оценка:
Здравствуйте, eao197, Вы писали:

E>А можно ли раскрыть эту тему по подробнее? Что именно плохо в приведенном коде (особенно с поправкой на то, что это врядли в точности тот код, который используется в реальной системе, а больше похож на быструю "выжимку" из оного)?


K>>> Node *nodes[3];
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.11.05 16:33
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>А можно ли раскрыть эту тему по подробнее? Что именно плохо в приведенном коде (особенно с поправкой на то, что это врядли в точности тот код, который используется в реальной системе, а больше похож на быструю "выжимку" из оного)?


K>>>> Node *nodes[3];


Я именно это и подразумевал, когда говорил, что код больше похож на выжику из production кода. Да и лечится эта проблема элементарно:
struct Triangle
{
   Node* node_at( int idx ) // кольцевой доступ
   {
      static const int imap[] = { 1, 2, 0, 1, 2, 0, 1 };
      return nodes[imap[idx+2]];
   }
  private :
   Node *nodes[3];
};


А еще более вероятно, что в реальной системе что-то вроде:
class Triangle
{
public :
    const Node * node_at( int idx ) const 
        { return nodes[ imap( idx + 2 ) ]; }
    Node * node_at( int idx )
        { return nodes[ imap( idx + 2 ) ]; }
private :
    Node * nodes[ 3 ];
    
    static const int imap( int idx )
        {
            static const int m[] = { 1, 2, 0, 1, 2, 0, 1 };
            assert( 0 <= idx && idx < (sizeof(m)/sizeof(m[0])) );
            return m[ idx ];
        }
};
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[18]: С++ culture
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 10.11.05 22:31
Оценка:
E>А еще более вероятно, что в реальной системе что-то вроде:

И это все шаманство будет быстрее, чем:
return nodes[(idx+2)%3];

?
Re[17]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.05 23:19
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Твой оппонент хотел сказать, что при проверке суждения часто оказываются ошибочными.


Видимо у него не получилось.

ПК> Соответственно, само по себе наличие исследований ни о чем, кроме интереса к теме, не говорит.


Ошибашся. Оно говорит, о том что есть некие задачи и некие идеи которые проверяются/решаются. Собсвенно идея Сингулярити довопльно проста — это создание безопасной и предсказуемой ОС. Как я понимаю, проект на том этапе когда можно говорить, что иди проверяемые в проекте подтвердились. Конечно до промышленной/коммерческой ОС еще далего, но говорить о Сингулярити как о каких-то там непроверенных задмуках мякго говоря не честно.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: С++ culture
От: Кузнецов Денис Викторович Казахстан  
Дата: 11.11.05 03:25
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Видимо у него не получилось.


Вот дела, и у меня теперь не получилось до Влада мысль довести. Уважаемый, дело не в окружающих...

ПК>> Соответственно, само по себе наличие исследований ни о чем, кроме интереса к теме, не говорит.


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


Влад, идей проверяется на миллион, причем в последствии оказывается полезными единицы. Таков мир. Опять же, ты домысливаешь "Как я понимаю, проект на том этапе когда можно говорить, что иди проверяемые в проекте подтвердились". А что ты в этом понимаешь? Ты участвовал в разработке какой-то OS? Я, к примеру, ничего не понимаю и не решаюсь судить. Хотя, подобных околовсяческих спецов я уже видал.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: С++ culture
От: c-smile Канада http://terrainformatica.com
Дата: 11.11.05 04:17
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, mrozov, Вы писали:


M>>По-моему — это факт.


AVK>Спорить о вкусе устриц, как это не печально, можно только с теми, кто их ел.


Если честно то я например устриц не ем.
Мне почему-то достаточно их запаха.

Это я так просто...
Re[19]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.11.05 04:48
Оценка:
Здравствуйте, DarkGray, Вы писали:

E>>А еще более вероятно, что в реальной системе что-то вроде:


DG>И это все шаманство будет быстрее, чем:

DG>return nodes[(idx+2)%3];

Думаю, что вполне возможно. Т.к. assert во время отладки удаляет все обращения по неверному индексу. В релизе, с большой вероятностью, все вызовы инлайнятся, а assert изымается, поэтому лишнего оверхеда нет. А в твоем варианте взятие остатка от деления будет всегда.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[19]: С++ culture
От: Kluev  
Дата: 11.11.05 08:14
Оценка:
Здравствуйте, DarkGray, Вы писали:

E>>А еще более вероятно, что в реальной системе что-то вроде:


DG>И это все шаманство будет быстрее, чем:

DG>return nodes[(idx+2)%3];

Это эквивалентный код, за исключением ошибки с %3, компилер все проинлайнит
Re[20]: С++ culture
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 11.11.05 08:25
Оценка:
K>Это эквивалентный код, за исключением ошибки с %3, компилер все проинлайнит

inline-же это не панацея.
беготня по нескольким разным кускам памяти все равно остается.
Re[17]: С++ culture
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.11.05 09:07
Оценка:
Здравствуйте, Кузнецов Денис Викторович, Вы писали:

КДВ>Не обращай внимания. Он по своей дурацкой привычке оппонента зачморить пытается.


Просьба больше не писать подобных бессодержательных сообщений.
... << RSDN@Home 1.2.0 alpha rev. 619>>
AVK Blog
Re[9]: С++ culture
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.11.05 09:07
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Если честно то я например устриц не ем.

CS>Мне почему-то достаточно их запаха.

Но, тем не менее, о их вкусе споришь Что и требовалось доказать
... << RSDN@Home 1.2.0 alpha rev. 619>>
AVK Blog
Re[15]: why off?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 11.11.05 10:33
Оценка:
Здравствуйте, VladD2, Вы писали:

ГВ>>Не хотите — не доказывайте, Ваше право. Но и не ждите серьёзного отношения к бездоказательным (сиречь — голосоловным) утверждениям.

VD>Твои утверждения не менее голословны.

Хммм... да... снятие шляпы я ничем доказать не могу. С этим не поспоришь.

VD>Что касается позиций, то я лично наблюдаю другую картину.


[skip, хотя я далеко не согласен]

VD>Короче, этот рассказ можно продолжать еще долго.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.05 14:23
Оценка:
Здравствуйте, Кузнецов Денис Викторович, Вы писали:

VD>>Видимо у него не получилось.


КДВ>Вот дела, и у меня теперь не получилось до Влада мысль довести. Уважаемый, дело не в окружающих...


У тебя не получилось ее правильно сформулировать.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.05 19:09
Оценка:
Здравствуйте, eao197, Вы писали:

Ш>>Так что что тут будет быстрее без исследования вопроса сказать сложно.


E>Это точно.


О, как? Не уж, то ты проникся мыслью, о неверности предполжений?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: С++ culture
От: Hydrogen  
Дата: 11.11.05 20:24
Оценка:
K>Суть в том что сишные-фиксированные массивы не аллоцируются сами по себе в хипе, а входят в состав обьекта, и все распределяется одним махом. Дотнетовские массивы должны распределится отдельно, т.е. один аллок на обьект и + несколько на массивы. В итоге в С++ будет распределено 200к обьектов, а в NET-e почти в 11 раз больше. Чувствуешь разницу? Или память это не ресурс? Фактически GC прийдется регулярно обрабатывать больше 2 млн обьектов. И это только часть от big picture.
Кстати помнится у Явы был какой-то гимор с Мусорщиком, который впервые был обнаружен в VoIP серверных приложениях- AFAIK гудка дожидались иногда по 40 секунд.
Как с этим у дотнета?
... << RSDN@Home 1.1.3 stable >>
Re[23]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.11.05 20:28
Оценка:
Здравствуйте, VladD2, Вы писали:

Ш>>>Так что что тут будет быстрее без исследования вопроса сказать сложно.


E>>Это точно.


VD>О, как? Не уж, то ты проникся мыслью, о неверности предполжений?


Каких предположений и какой неверности? (см. Re[21]: С++ culture
Автор: eao197
Дата: 11.11.05
)
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: С++ culture
От: Awaken Украина  
Дата: 11.11.05 20:36
Оценка:
>> GC из .NET -- не ужасен, просто он несколько /другой/. Именно это и
>> пугает.

C>GC? Пугает? Хахахахаха.....


пугает? не то слово. БЕСИТ!
Re[24]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.05 22:30
Оценка:
Здравствуйте, eao197, Вы писали:

E>Каких предположений и какой неверности? (см. Re[21]: С++ culture
Автор: eao197
Дата: 11.11.05
)


Ш>>>>Так что что тут будет быстрее без исследования вопроса сказать сложно.


E>>>Это точно.


Или ты что-то другое имел в виду?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.05 22:30
Оценка:
Здравствуйте, Awaken, Вы писали:

C>>GC? Пугает? Хахахахаха.....


A>пугает? не то слово. БЕСИТ!


А что бисит то?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.05 22:30
Оценка:
Здравствуйте, Hydrogen, Вы писали:

H>Кстати помнится у Явы был какой-то гимор с Мусорщиком, который впервые был обнаружен в VoIP серверных приложениях- AFAIK гудка дожидались иногда по 40 секунд.

H>Как с этим у дотнета?

Никаких проблем. Сборка мусора в худшем случае занимает милисекунды.

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

Кстати, я пришел к забавнейшему выводу. Дотнетный ЖЦ очень хорошо ведет себя в реальной жизни и не очень здорово выглядит в синтетических тестах. Ребята из МС явно оптимизировали ЖЦ не под тесты.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: С++ culture
От: GU Glez  
Дата: 12.11.05 10:20
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Кстати, ты все же ошибашся. Есть таки очень разумные и весьма дальновидные люди которые пишут драйверы на C#. Правда, другим они пока это делать не предлагают, но когда-нибудь это обязательно произойдет.
VD>Откуда они? Из MS Research. Занимаются они разработкой уравляемой ОС.

Ага. Только, как всегда для совместимости свехру вниз введут еще столько новых уровней API и новых технологий с разными уровнями абстракции. А для успокоения "неугодных" и "неправильно" мыслящих заплатят PR-щикам пару десятком мильонов, чтобы те переубедили "неугодных" и показали им, как все будет хорошо потом, когда привыкнешь
С уважением,
GU Glez [Джи Ю Глиз]
Re[16]: С++ culture
От: GU Glez  
Дата: 13.11.05 16:36
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>А тут я скорее с ними соглашусь. "Неправильно мыслящие" это действительно проблема. Концепция которую может развивать одна копрпорация может быть только одна. А разброд и шатания приведут только к ненужным прыжкам и сменам концепций.
VD>Всегда найдутся люди которы, к примеру, не понравятся ХМЛ-ные теги и которые начнут агетировать за некую экзотику. MS же, с San-ом и IBM-ом стараются следовать стандартам и продивагать технологически и научные разработки в массы. И крикуны тянущие повозку в разные стороны тут только мешают.
VD>Они конечно думаю, что только их мысли являются правильными. Вот только это их личные проблемы. Пусть сами свои мысли в жизнь и воплощают.
VD>Народ же к сожелению не может четко определить перспективные технологии от крикунских. И PR тут становится самым простым способом убеждения. Люди по умнее фильруют PR и улавливают суть.
VD>Собственно "крикуны" — это тоже PR.

Так-то оно так. Да только вот стандарты эти меняются каждый раз. Меняются и обещают (всегда) одно и тоже! В технологиях MS всегда наблюдается одна, не очень утешительная, тенденция — суть новой технологии — это затирание логических, архитектурных, проектных и т.п. ошибок, допущенных в прошлом. Причем с тем же самым рвением (и словами прошлых оппонентов) с которым эти самые ошибочные технологии создаваились и PR-лись. Тут где-то на РСДН была фраза: "MS придумало C#, потому что на C++ писать так и не научились ".

Смысл моего поста именно в том, что для достижения каких-либо целей будут вводится новые технологии, новые уровни абстракции. А по прошествии кое-какого времени и для этих старых и для будущих новых будут вводиться еще более новые уровни, новые языки.
Конечно хорошо мыслить на разных языках созданных конкретно под каждую технологию и проблему. Но это, как говориться, мы уже проходили...
С уважением,
GU Glez [Джи Ю Глиз]
Re[17]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.11.05 22:58
Оценка:
Здравствуйте, GU Glez, Вы писали:

GG>Так-то оно так. Да только вот стандарты эти меняются каждый раз. Меняются и обещают (всегда) одно и тоже! В технологиях MS всегда наблюдается одна, не очень утешительная, тенденция — суть новой технологии — это затирание логических, архитектурных, проектных и т.п. ошибок, допущенных в прошлом.


Я бы сказал, что дело не в ошибках. Дело в том, что на каждом новом витке развития они создают более чистые, целостные и амбициозные решения. Естественно, что при этом решения становятся значительно сложнее. Собсвенно ДОС на асм-е, ВыньАПИ 1.0-3.х (16), КОМ, дотнет можно рассматривать как общую линию развития.

GG> Причем с тем же самым рвением (и словами прошлых оппонентов) с которым эти самые ошибочные технологии создаваились и PR-лись.


PR есть PR. Нужно уметь разливать его и зрить в корень. Все же PR используется для продвижения того что компания считает перспективным. Он ведь не самоцель.

GG>Тут где-то на РСДН была фраза: "MS придумало C#, потому что на C++ писать так и не научились ".


Я бы сказал так. Когда в МС научились писать на C++, то написали дотнет и C#.

GG>Смысл моего поста именно в том, что для достижения каких-либо целей будут вводится новые технологии, новые уровни абстракции. А по прошествии кое-какого времени и для этих старых и для будущих новых будут вводиться еще более новые уровни, новые языки.


Несомненно. И для их быстрого постижения нужно уже сейчас изучать то, что является их прототипом сегодня.

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


Когда я говорил о необходимости знания нескольких языков, то в первую очередь имел в виду языки общего назначения. Но конечно знание DSL-ей тоже полезно. По крайней мере как хороший паттерн решения проблемы сложности.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: С++ culture
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 15.11.05 11:30
Оценка:
vdimas,

VD>>Можно по подробнее о проблемах с написанием using-га?


V>
V>using (MyRAII1 r1 = new MyRAII1())
V>{
V>    using (MyRAII2 r2 = new MyRAII2())
V>    {
V>        using (MyRAII3 r3 = new MyRAII3()) 
V>        {
V>            using (MyRAII4 r4 = new MyRAII4()) 
V>            {
V>                ...
V>                ...
V>            } 
V>        }
V>    }
V>}
V>


V>бррр


А что собственно "бррр"? И тем более чем не угодил первый вариант? И наконец, может есть третий вариант, который лучше их обоих?
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[15]: полный off
От: mbergal  
Дата: 15.11.05 16:43
Оценка:
Здравствуйте, mrozov, Вы писали:
[...]
M>Выхожу из такого разговора я, обогащенный новыми знаниями и расширившимся взглядом на мир. Надеюсь, что это же можно сказать и о моих собеседниках. Хотя это и не главная цель.

А какая главная? И какие другие?

Типа:

1. ...
2. Приобретение мною новых знаний и расширение моего взгляда на мир.
3. ...


M>Всего доброго.
Re[15]: why off?
От: kliff Россия http://www.esignal.ru
Дата: 16.11.05 08:22
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Короче, этот рассказ можно продолжать еще долго.


Тебя наверное сильно задел такой фанатик) Кстати ты чем-то похож на него, без обид только.
Re[11]: С++ culture
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 16.11.05 12:44
Оценка:
vdimas,

LCR>>А что собственно "бррр"? И тем более чем не угодил первый вариант? И наконец, может есть третий вариант, который лучше их обоих?


V>В синтаксисе using не учтена возможность использования нескольких ресурсов на одном и том же уровне вложенности. И, если честно, то мне даже трудно представить себе последовательность раскрутки стека, даже в случае наличия такого синтаксиса, если при создании одного из ресурсов произошла исключительная ситуация. Эту ситуацию в C# описывают ручками и городят уровни вложенности там, где логически они не нужны.


Раскрутка такая же как при вложенных {try — catch — finally}'ах.

Один уровень вложенности вместо четырёх — not a big deal, гораздо важнее ограничение области видимости, а оно есть в обоих вариантах.

По сравнению со вложенными {try — catch — finally} using выглядит симпатичнее, вот я и удивился.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[11]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.11.05 14:26
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>А зачем мусор в правой части?


Это что, незаконный синтаксис для С++? Код в общем-то условный. Ты же не думашь, что объекты пасущие ресурсы будут получать информацию телепатически. В рельном коде там будет еще немало инициализирующего кода.

ПК> И зачем скобки после r4?


Иначе код будет не идеттичным. Обаласть видимости юсиноа именно такая. Без скобок она будет слишком широкой.

ПК>Плюс, если автор пишет короткими функциями, окружающие скобки скорее всего будут скобками функции, содержащей данный код.


И в юсинге их не будет.

Более того. Лично у меня вообще юсингов не так много в коде. Многие из них скрыты в библиотеках или других оператороах. Например, foreach тоже делает using если у итератора реализован IDisposable.

PS

В общем, это довольно несерьезное обсуждение. Надо очень долго и упорно заниматься аутотренингом, чтобы поверить в то, что ручное управление памятью не приводит к усложнению программ и увеличению ошибок. В то же время упраление внешними ресурсами таких проблем не дает.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.11.05 16:27
Оценка:
Здравствуйте, vdimas, Вы писали:

VD>>А какая разница? Я не призивал использовать Сингулярити для создания копрпоротивных веб-порталов. Я просто заметил, что есть таки вполне разумные люди — ученые, которые пишут драйверы на C#. Пускай это пока что игрушка ученых, но идея эта уже далеко не бредовая.


V>Не ученых, а инженеров.


У тебя уже пунктик на инженерах выработался.

Именно ученых. Я бы даже сказал исследователях.

V> Да, кстати, чем, по твоему, драйвер отличается от обычной программы? (раз их разработку на C# могут делать только ученые )


Я вот никак понять не могу, что тебя все время тенят на искажение чужих слов и вообще на демагогию?

Где сказано, что "их разработку на C# могут делать только ученые"?

По-моему вопрос кто и что делает для этой ОС очевиден и обсуждения не требует.

V>Я могу ответить — чем. Непосредственным обращением к аппаратуре. Что есть непосредственное обращение к аппаратуре? Это запись/чтение в память, общение с портами ввода/вывода (что можно рассматривать как частный случай обращения к немного другой памяти), а так же реакция на прерывания.


Почитай про микроядерную архитектуру. Глядишь твое мнение о том, что должен делать драйвер и изменится.

Задача драйвера устройсва — взаимодействовать с устройством на низком уровне обеспечивая высокоуровневый протокол для ОС и прикладных программ. При этом нет реальной необходимости непосредственно обращаться к аппаратуре и делать все остальное перечисленное тобой. Все обращения к портам и т.п. можно скрыть за очень небольшим по объему HAL-ом который будет выглядеть для драйвера как некое универсальное АПИ.

Что же касается о невозможности обращаться к адресам памяти на C#, то это скорее говорит о товем знании C# нежели о его ограничениях.

V>Может программа на C# непосредственно обращаться к портам ввода/вывода? или по фиксированным адресам памяти? Или настраивать внутренние регистры процессора на новые карты отображения виртуальных устройств ввода/вывода? НЕТ. И никогда не сможет by design. Очевидно, надо на ASM/C/C++ написать требуемый функционал, и приподнести его "на блюдечке" управляемой среде в виде простых интерфейсов. Реально это? Вполне. Разработка "научная"? гх-гхх


По твоим словам получается разработчики Сингулярити нагло врут утверждая, что драйверы устройств написаны на C# без использования опасного кода. Но я почему-то скронен верить именно им, а не тебе.

Что касается научности, то опять таки мнение гордого инжинера тут вряд ли окажется весомым. Цели исследований описаны на сайте проекта. То что эти цели счтены научными сомнений не вызвает, так как занимаются этим люди из университетов.

Ты же, как всегда, с целью облить что-то неугодное тебе грязью выцепляшь из контекста какие-то одтельные веши и пыташся их "разоблочить". Зачем? Я не знаю. Но цедь явно не добрая.

ЗЫ

В общем, почитай про миноядерную архитектуру и идею HAL. Тогда возможно разговор на эту тему у нас и получится.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: полный off
От: mrozov  
Дата: 16.11.05 17:13
Оценка:
Я имел в виду, что помогать другим — не главная моя цель. Я, в общем-то, эгоист. Соответственно, даже наверняка зная, что кто-то не прав — переубеждать через силу я не буду.
Re[19]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.05 01:19
Оценка:
Здравствуйте, vdimas, Вы писали:

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


А читать ты уже разучился? Если еще нет, то читай http://research.microsoft.com/os/singularity/

VD>>Именно ученых. Я бы даже сказал исследователях.


V>Да, и что исследуем?


Singularity is a research project focused on the construction of dependable systems through innovation in the areas of systems, languages, and tools. We are building a research operating system prototype (called Singularity), extending programming languages, and developing new techniques and tools for specifying and verifying program behavior.


V> Вроде же можно пойти почитать про микроядерную архитектуру?


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

V> Любой экперимент — априори исследование.


+1

V> Дык, я тогда тоже ученый.


Ты нигилист. Так что толку от твоих исследований не много.

V> Где гипотезы, выкладки, расчеты и доказательства? Нету?


ftp://ftp.research.microsoft.com/pub/tr/TR-2004-105.pdf
ftp://ftp.research.microsoft.com/pub/tr/TR-2005-135.pdf
И вообще потыкай по ссылочкам на главной стрнице проекта.

V> то-то и оно... Доказывать нечего, надо "брать и делать". Инженерная разработка чистой воды.


И все то ты знашь. Хрошо все таки, что и научные планы тебе тоже никто делать не даст.

VD>>По-моему вопрос кто и что делает для этой ОС очевиден и обсуждения не требует.


V>Грамотные инженеры реализуют очередную задумку, действительно, обсуждать нечего.


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

VD>>Почитай про микроядерную архитектуру. Глядишь твое мнение о том, что должен делать драйвер и изменится.


V>А если нет?


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

V>Или существует только микроядерная архитектура?


Нет конечно. Я даже не уверен, что микроядерная архитектура применена в этой ОС. Просто она сдесь наиболее логична. Да и очень похоже по описанию. Как и в классической микроядерной ОС драйверы являются отдельными процессами, а общение между процессами осуществляется с помощью сообщений. Вряд ли для такой ОС можно применить монолитный подход из Линукса.

VD>>Задача драйвера устройсва — взаимодействовать с устройством на низком уровне обеспечивая высокоуровневый протокол для ОС и прикладных программ. При этом нет реальной необходимости непосредственно обращаться к аппаратуре и делать все остальное перечисленное тобой. Все обращения к портам и т.п. можно скрыть за очень небольшим по объему HAL-ом который будет выглядеть для драйвера как некое универсальное АПИ.


V>Это ты споришь или соглашаешься?


Я тебя поправляю. Если не доходит, скажу более прямо. В задачи драйвера не обязаны входить

непосредственное обращение к аппаратуре, то есть запись/чтение в память, общение с портами ввода/вывода, а так же реакция на прерывания

.

И на надо делать вид, что ты говорил то же самое.

V> вот из моего предыдущего поста:

V>
VD>>Очевидно, надо на ASM/C/C++ написать требуемый функционал, и приподнести его "на блюдечке" управляемой среде в виде простых интерфейсов.

Начнем с того, что С/С++ точно так же как и C# не имеют средств общения с аппаратурой, так как являются аппоратно независимыми языками. Точно так же С/С++ не имеют ни какого приемущества с точки зрения манипуляций с памятью (если говорить о небезопасном режиме). Так что слова про С/С++ — это вообще мягко говоря не правда/заблуждение.

Что касается "преподнесения на блюдечке", то это тоже какая то фигня. Несомненно машинные коды/асм необходимы в микроядре, так как без них просто невозможно обращение к тем самым I/O-портам, работа с прерываниями и т.п. Однако даже в NT и ее потомках этот код микроскопически мал. И то что драйвер может лезть к аппаратуре напрямую еще не значит, что он должен это делать. А уж в исследовательской ОС основными фичами которой является надежность и предсказуемость — это само самой разумеется. По этому она принципиально построена на миниатюрном HAL предоставляющем универсальный доступ к железу.

Назвать наличие HAL-а предоставлением на блюдечке чего-то от барского стола С++ у меня даже язык не поворачивается.

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

V>Понимаешь, HAL она такая штука, что ее границы можно выбирать произвольно. Если сделать высокий уровень абстракций, то львиная доля кода перекочует в тот самый unmanaged, и блоки HAL под конкретные модели конкретных железяк в все так же будут разрабатывать вне C#.


Авторы Сингулярити открытым текстом сказали, что ОС и драйверы устройств разрабоатываются на безопасном подмножестве C#. И пока я не услышу громкие громких разоблочений их лжи, я склонен верить им, а не экспетрам во всех областях вроде тебя.

V>Поэтому понятие "драйвер на C#" требует нового осмысления .


Такая глубокомысленная фраза, что и сказать то по ней нечего.

VD>>Что же касается о невозможности обращаться к адресам памяти на C#, то это скорее говорит о товем знании C# нежели о его ограничениях.


V>Если ты про unsafe, то они же ведь собрались его постепено выкинуть, именно начиная с этой ОС, т.к. необходимость пропадет. И к портам все-равно невозможно обращаться. А при наличии HAL — и к памяти можно не обращаться.


Ну, начем с маааленького такого замечания. Ты опять вывертывашся. Ты утверждал о невозможности обращаться к адресам памяти на C#. Ну, так будь добр или согласиться с тем, что ты в очередной раз ошибся, или доказать свои утверждение. А вот заниматься в очередной раз флудом не стоит. Право это уже надоело.

Теперь что касается "они же ведь собрались его постепено выкинуть".
Жаль они об этом не знают. В их задачи входит создание максимально надежной ОС. По этому они конечно стремятся минимизировать объем небезопасного кода. Однако из этого никак не проистекает, тот факт, что небезопасного кода в ОС нет вовсе или что весь он написан на С++. Собственно разработчики этой ОС прямым текстом говорят, что тот же ЖЦ написан с использованием небезопасного режима C#.

Короче, в очередной раз обсуждать нечего. Твои слова просто не соответсвуют действительности.

V>>>Может программа на C# непосредственно обращаться к портам ввода/вывода? или по фиксированным адресам памяти? Или настраивать внутренние регистры процессора на новые карты отображения виртуальных устройств ввода/вывода? НЕТ. И никогда не сможет by design. Реально это? Вполне. Разработка "научная"? гх-гхх


VD>>По твоим словам получается разработчики Сингулярити нагло врут утверждая, что драйверы устройств написаны на C# без использования опасного кода. Но я почему-то скронен верить именно им, а не тебе.


V>Блин, я же сам в том посте и предположил, как именно это сделано. Это все и так понятно, в общем мимо.

V>Речь о том, что когда начнут вставлять реальные железки в реальные компы, то часть имплементации HAL возможно придется писать производителям железок. И не на C#.

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

V>Да, именно, целые университеты занимаются инженерными разработками. Не накладывай совковую модель институтов на них, они сильно отличаются.


Нда, это действительно какой-то инженерный комплекс. Гордость звания инженера перекрывает все вокруг.

Понимаеш ли, инженер — это специалист с высшим техническим образованием. Так что любой ученый технической специализации автоматом является инженером. Более того инженерия — это творческая техническая деятельность, что очень близко к научной деятельности. Так что несомненно любую научную деятельность в технической сфере можно причислить к инженерной деятельности. Однако научная деятельность тем и отличается, что практически на 100% является исследовательской, в отличии от инженерной, которая в основном присутсвует в чисто практических областях.

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

В данном случае речь идет о компьютерой науке (computer science), так как данное исследование дает знания всему человечеству.

V>И всем плевать на мнение или там несогласие мое или твое. Есть довольно ощутимые границы научной и инженерной деятельности.


Я кончно понимаю, что ты очень любишь слвово "инженер", но все же еще неплохо было бы знать значения используемых терминов. К тому же еще неплох было бы понимать, что бывает наука прикладная, а бывает фундаментальная.

V>Научная:

V>

    V>определения и аксиомы;
    V>теоремы;
    V>доказательства;
    V>интерпретация результатов.
    V>


V>Инженерная:


V>

    V>определение требований;
    V>написание спецификаций;
    V>разработку и реализацию;.
    V>тестирование и анализ.
    V>

Это очень примитивное и узкое понимание того чем занимается наука и инженерия. Более широкое трактование я уже привел выше.

VD>>Ты же, как всегда, с целью облить что-то неугодное тебе грязью выцепляшь из контекста какие-то одтельные веши и пыташся их "разоблочить". Зачем? Я не знаю. Но цедь явно не добрая.


V> я плакаль... И почему я не позволяю себе подобных высказываний в адрес оппонента?


Я говорю о том, что вижу. Ты уж меня извени, но привык я так. Если вижу, что кто-то ворует — я говорю ворует. А если вижу, что беспречинно грязью что-то обливает, то говорю что обливает. Ну, а о том, что ты повзоляешь сам себе я и говорить то не хочу.

V> На любой твой выпад можно отвечать этими словами. Специально сохранил в "избранном" линк сюда.


Коллеционируй.
Что до выпадов. То я нападаю на то, в чем вижу конкретные недостатки и стараюсь разбираться в том на что нападаю. Ты же просто от болды пытаешся принизить значимость того или иного дела или оговорить его. Вот в этом и разница.

V>И кстати, я не пытаюсь разоблачить, я не согласен кое с чем и привожу аргументы.


Где аргументы то? Ты даже определения слов не знашь.

VD>>В общем, почитай про миноядерную архитектуру и идею HAL. Тогда возможно разговор на эту тему у нас и получится.


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


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

V>(Согласись, твои отсылки "пойти почитать, только тогда снизойду" на грани оффтопа, как и мой ответ )


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

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


Ага. Вместо того чтобы в чем-то разобраться куда проще указать на черезмерную приверженность и нетерпимость оппонента.

В общем, я не против обсудить эту тему. Но объяснять все с нуля не буду. Как минимум я не имею должной компитенции, а вопрос разянен в тонне статей доступных в Интернете. Так что если хочешь конструктива, прочти любое введение. А иначе давай завяжем.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: С++ culture
От: mrozov  
Дата: 17.11.05 08:25
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Согласен. Дотнет отберет прилично задач не только у Явы, но и у С++. Ну и на здоровье. Самое правильное — использовать наиболее подходящий инструмент для каждой задачи. С++ приобретет легкий оттенок "системного" языка, а про С мы наверно забудем.


Я тут, собственно, именно об этом и говорю. А меня бьют лопатами.
Re[10]: С++ culture
От: mrozov  
Дата: 18.11.05 10:50
Оценка:
В целом согласен. И о согласии с этой точкой зрения неоднократно заявлял выше, уважаемые товарищи с лопатами.
Но! Осмелюсь утверждать, что не "посмотрим через годик", а "посмотрели год назад".
Re[12]: С++ culture
От: mrozov  
Дата: 18.11.05 13:08
Оценка:
Здравствуйте, vdimas, Вы писали:


V>--------

V>Мы сами используем на одной из составных частей нашей системы C#. И пол-года назад я прошерстил весь интернет на предмет наличия готовых нормальных высокоуровневых фреймворков (а что, раз уж принято решение использовать C#, дык его надо выдоить до последней капли), ан нет... Как я уже высказался — куча слабосвязанных поделок, многие из которых претендуют максимум на слабоотработанный макет. Поэтому приличную часть енжина в своей системе делали ручками. Спасибо IT за удачную реализацию маппинга.

Ну а мы сделали свой. Хватает с головой. Причем реализация для Java потребовала бы не меньше усилий. Точно также могу сказать, что для java ничего нет. Хотя там ситуация намного лучше.

Но я, честно говоря, не очень понимаю, как это мы ловко перескочили на java? При чем тут она? Java — рулит, но какое это имеет отношение к предмету разговора?
Re[13]: С++ culture
От: Cyberax Марс  
Дата: 18.11.05 15:22
Оценка:
mrozov wrote:

> Ну а мы сделали свой. Хватает с головой. Причем реализация для Java

> потребовала бы не меньше усилий. Точно также zмогу сказать, что для
> java ничего нет. Хотя там ситуация намного лучше.

Для Java есть Hibernate (http://www.hibernate.org), которого обычно
вполне хватает. Есть порт на .NET — NHibernate, но он в вечной альфе.

Вообще, для Java есть такая огромная куча свободного софта, что .NETу
еще оооочень долго придется догонять Java.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[14]: off
От: mrozov  
Дата: 18.11.05 15:32
Оценка:
Здравствуйте, Cyberax, Вы писали:


C>Для Java есть Hibernate (http://www.hibernate.org), которого обычно

C>вполне хватает. Есть порт на .NET — NHibernate, но он в вечной альфе.

Да ну? Релиз проспали? =)
Обычно — да, но не нам.

C>Вообще, для Java есть такая огромная куча свободного софта, что .NETу

C>еще оооочень долго придется догонять Java.

У Java нет за спиной MS. Поэтому java .net не догонит вообще никогда

Но! Я еще раз спрашиваю — при чем тут вообще Java, товарищи? И сам же себе отвечаю — непричем. Про .net vs java — это совсем в другую ветку.
Re[15]: off
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 18.11.05 17:16
Оценка:
Здравствуйте, mrozov, Вы писали:

M>Но! Я еще раз спрашиваю — при чем тут вообще Java, товарищи? И сам же себе отвечаю — непричем. Про .net vs java — это совсем в другую ветку.


Но как это не при чем? Обсуждается, куда же с плюсов уходить. Хорошим тоном на RSDN считается, что в .NET и C#
А вот такая альтернатива, как Java, почему-то не рассматривается. Хотя, как верно здесь подмечают, сейчас Java обвешана сопутствующими инструментами и технологиями гораздо круче C#.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: off
От: Cyberax Марс  
Дата: 18.11.05 18:12
Оценка:
mrozov wrote:

> C>Для Java есть Hibernate (http://www.hibernate.org), которого обычно

> C>вполне хватает. Есть порт на .NET — NHibernate, но он в вечной альфе.
> Да ну? Релиз проспали? =) Обычно — да, но не нам.

Ух, а еще месяца 4 назад все в альфе было.

> C>Вообще, для Java есть такая огромная куча свободного софта, что .NETу

> C>еще оооочень долго придется догонять Java.
> У Java нет за спиной MS. Поэтому java .net не догонит вообще никогда

Зато есть Sun, IBM, BEA, Apache и другие...

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[15]: С++ culture
От: vdimas Россия  
Дата: 18.11.05 18:50
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Ты не обращал внимание на такое?

GZ>struts vs ASP.NET

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

GZ>Spring.NET


Спасибо за линк, даже как-то не приходило в голову поискать такое. Посмотрим, и наличие инструментария в т.ч.
Re[15]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 21.11.05 09:25
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Ты не обращал внимание на такое?

GZ>struts vs ASP.NET

Интересное чтиво. Складывается впечатление "Белые начинают и прогрывают" Где "белые" -- это Sun и Java, а проигрывают как раз из-за того, что первыми начинают, набивают шишки, выбират направление, прокладывают просеку... И оказываются укатанными в асфальт катком марки ASP.NET под управлением .NET Framework

Но мне там одна фраза понравилась:

Unlike J2EE, in which the Application Server is completely independent from the OS, the .NET Application Server is the Microsoft Windows® Operating System (and the services provided by Windows). The .NET Framework was designed to integrate closely with IIS and COM+ to provide reliable application hosting services and native support for Web services standards like XML, SOAP, UDDI and WSDL. This integration provides a significant performance boost to .NET applications, but requires platform monogamy. The level of integration is much tighter than with any J2EE server, and results in more features and faster performance.


Понятно, что речь здесь идет, в основном, об ASP.NET, но и вся платформа .NET производит такое же впечатление. Поэтому, если кто-то занимается кроссплатформенной разработкой на C++ и хочет перейти на другую платформу/язык, то ему нужно смотреть не в сторону .NET от MS, а в сторону Mono или dotGNU. Не знаю, какие перспективы у Mono (хотя де Иказа был замечен в успешно стартовавших, но не доведенных до конца проектах, вроде Midnight Commander), а вот разработки GNU отличаются длительными сроками реализации (достаточно вспомнить GNU Classpath).
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: С++ culture
От: vdimas Россия  
Дата: 22.11.05 08:58
Оценка:
Здравствуйте, eao197, Вы писали:

E>Здравствуйте, GlebZ, Вы писали:


GZ>>Ты не обращал внимание на такое?

GZ>>struts vs ASP.NET

E>Интересное чтиво. Складывается впечатление "Белые начинают и прогрывают" Где "белые" -- это Sun и Java, а проигрывают как раз из-за того, что первыми начинают, набивают шишки, выбират направление, прокладывают просеку... И оказываются укатанными в асфальт катком марки ASP.NET под управлением .NET Framework


Есть и еще кое-что. ASP.Net-среда (организация инструментария) так и подталкивает на написание кода в стиле Дельфи (с переносом на особенности web). Напротив, struts прямо-таки навязывает компонентный слабосвязанный подход. В сочетании со Spring можно получить практически тот самый идеально-утопический процесс построения приложений из кирпичиков-компонентов и ничего более. Т.е. механизм как бы уже есть, осталось развить соотв. базу CASE-средств по визуальному обслуживанию/конфигурированию этого механизма. Помните, были весьма популярны все эти обсуждения CASE-подходов в 95-98-м. ИМХО, ситуация близка к воплощению тех задумок, правда, немного с противоположной стороны. Сначала разработана гибкая среда исполнения компонентов, а потом стало очевидно, что, раз уж управление связями компонентов задается в run-time путем конфигурирования, то этот процесс вполне поддается автоматизации.

В той же ASP.Net, даже если мы вели разработку "правильно", т.е. создавали свои специализированные Web-контролы и компоненты, их объединение и layout выполняется все-равно в design-time в целевых web-страницах.
Re[17]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 22.11.05 11:26
Оценка:
Здравствуйте, vdimas, Вы писали:

V>В той же ASP.Net, даже если мы вели разработку "правильно", т.е. создавали свои специализированные Web-контролы и компоненты, их объединение и layout выполняется все-равно в design-time в целевых web-страницах.


Мне вообще-то сложно судить о веб-разработках, но вот наткнулся на интересный взгляд на Java: It's the End of the World as We Know It. Примечательна последняя фраза:

But most of all, what Java needs -- for the first time I can think of -- is not just someone who can design software or APIs well, it needs "the vision thing".

Вполне возможно, преимущество M$ сейчас как раз в наличии этой "the vision thing".
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: С++ culture
От: rombeck Израиль http://www.livejournal.com/users/rombeck
Дата: 22.11.05 18:04
Оценка:
Здравствуйте, VladD2, Вы писали:


КДВ>> Они хоть на бумаге могут писать эти драйвера. Это ж Research!!!


VD>А какая разница? Я не призивал использовать Сингулярити для создания копрпоротивных веб-порталов. Я просто заметил, что есть

VD>таки вполне разумные люди — ученые, которые пишут драйверы на C#. Пускай это пока что игрушка ученых, но идея эта уже далеко
VD>не бредовая.

Ну если существуют ОС, полностью написанные на Java (JavaOS) и на Обероне, почему бы и не существовать ОС, полностью написанной на C#?

А вот будет ли эта ОС развиваться и практически применяться — вопрос другой...
... << RSDN@Home 1.2.0 alpha rev. 619 on Windows 2003 5.2.3790.65536 2.0.50727.42>>
С уважением,
Роман Беккер
свои 5 копеек
От: bazilxp  
Дата: 23.11.05 11:50
Оценка:
Здравствуйте, Ligen, Вы писали:

L>"Слава, слава дракону!"

L>Навеяно агрессивными постами дотНетовцев, похвально стремящихся к мировому господству (ветка писал на с++
Автор: VladD2
Дата: 18.10.05
).

L>Дескрипшн: No holy wars. Зачем?

L>Можно наблюдать интереснейшую тенденцию:

Профессиоанальное становление :
1)Приобритение стиля .
2)способ реализации адвектный требованиям проекта .
3)И знания при этом никогда лишними не бывают.

Реальность такова пусть то .NET пусть C++ или еще какие либо модные слова/технологии.
Практическая сторона сроки X денег Y и реально работающие вещи ,а то что кому то хочется
чтобы это было хорошо написано в форуме пускай так оно и будет
... << RSDN@Home 1.2.0 alpha rev. 618>>
Re[21]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.12.05 16:36
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Ориентируясь же на произвольную архитектуру необходимо операционке предоставить унифицированный доступ к этим фичам. Разумеется, не через inp() и outp(), а именно через более высокий абстрактный уровень.


Да какая разница где и как будет реализовано абстрагирование от тонкостей аппаратуры? Ты же ведь другое изначально утверждал. Ты утверждал, что невозможно на C# писать ОС так как он что-то там не может. Синклер тебе верно заметил, что то что действительно не возможно вылевается в 2-3 функции работы с портами. А все остальное пишется с их использованием. Функции эти в общем-то примитивный и могут быть просто написаны в машинных кодах. Вот погляди как ТК в свое время сделал стаб-код для работы с APC в Виндовс.

В общем, хреново ты развеял "заблуждения" Синклера.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: С++ culture
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.12.05 21:13
Оценка:
Здравствуйте, VladD2, Вы писали:

Pzz>>Ух, я этого не знал. Т.е., MS-DOS (Windows 3.1), но с защитой при

Pzz>>компиляции. Прекрасная ОС, ничего не скажешь...

VD>В MS-DOS небыло ни процессов ни, ни сообщений, ни потоков. Короче нихрена в ней небыло.

VD>Сингулярити это скорее нечто на тему Оберон-ОС.

Offtopic: Над Виртом часто подшучивают и не принимают всерьез, а ведь он довел до промышленного состояния то, над чем сейчас экспериментируют в Microsoft -- Оберон-ОС.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[24]: С++ culture
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.12.05 22:56
Оценка:
VladD2 wrote:
>
> Pzz>NT никогда не была микроядерной ОС. Ядро НТ монолитно,
>
> Windows NT microkernel
> <http://www.google.ru/search?hl=ru&amp;q=Windows+NT+microkernel&amp;lr=&gt;
> http://en.wikipedia.org/wiki/Windows_NT

Википедия повторяет распостраненное заблуждение.

Вот Minix — микрокернел. QNX — микрокернел. MACH3, говорят, микрокернел
(а следовательно, и MacOS X — микрокернел). А NT — не микрокернел.
Posted via RSDN NNTP Server 2.0
Re[25]: С++ culture
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.12.05 23:01
Оценка:
eao197 wrote:
>
> Offtopic: Над Виртом часто подшучивают и не принимают всерьез, а ведь он
> довел до промышленного состояния то, над чем сейчас экспериментируют в
> Microsoft -- Оберон-ОС.

В Мелкософте над чем только не экспериментируют. Не надо принимать их
эксперименты слишком уж близко к сердцу. Цель этого эксперимента —
доказать, это C#, .Net и managed code 1) интересны для исследователей 2)
годятся для системного программирования.

Если посмотреть на их другие исследовательские проекты, то они все такие
— или про .Net, или про WiFi.
Posted via RSDN NNTP Server 2.0
Re[25]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.12.05 00:15
Оценка:
Здравствуйте, Pzz, Вы писали:

>> Windows NT microkernel

>> <http://www.google.ru/search?hl=ru&amp;q=Windows+NT+microkernel&amp;lr=&gt;
>> http://en.wikipedia.org/wiki/Windows_NT

Pzz>Википедия повторяет распостраненное заблуждение.


Ничего она не повторяет. Там сказано то что было на самом деле. ОС проектировалась как микроядерная, но в ходе разработки в ядро засовавались все большие и большие куски тем самым уводя ОС в сторону монолитных. На сегодня это гибрид.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: С++ culture
От: vdimas Россия  
Дата: 05.12.05 09:53
Оценка:
Здравствуйте, VladD2, Вы писали:

V>> Я реально имел дело с совершенно различными по уровню HAL, и знаю о чем говорю. Понятие HAL никак не пересекается с архитектурой ОС.


VD>В общем-то после этоих слов уже дальше говорить не о чем. Наличие HAL-а как раз и говорит о ориентации ОС на минкроядерную архитектуру.


Бред полный. Наличие HAL-а говорит лишь об обстрагировании от железа. С чего ты делаешь подобные выводы? Ознакомился бы с вопросом наличия HAL в современных ОС, в том числе и встраиваемых, которые никогда не будут микроядерными. HAL есть практически везде. Так что, странное заявление.

VD>Собственно зачем монолитной ОС HAL если любой драйвер может залезть в любой аспект железки?


Не только драйвер, но и ОС, правда?
HAL — это абстракция, иногда довольно-таки высокоуровневая. Ее цель — действительно развязаться от железа, и от процессора в т.ч. Смешной вопрос, право. Для того, чтобы ответить на него, надо элементарно составить список ф-ий, которые содержат HAL различных ОС. Оставляю как домашнее задание (для WinXX, Linux, и кучи встраиваемых, в ответе Синклеру указал, где копать)

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


VD>С чего бы это? Наоборот требуется минимальное ядро абстрагирующее от самых тонких вещей. Далее дрова работая через это микроядро абстрагируют ОС от остальных деталей реализации железа.


Блин, туго. Возьми для примера таймер. Сколько нужно приседаний, чтобы создать этот объект ядра? Причем эти приседания зависят от количества, способа обращения и интерпретации результатов работы внешних таймеров, а некоторые реализации вообще обходятся БЕЗ внешних аппаратных таймеров (в WinXX, в которых внешние таймеры задействованы для других нужд). Применительно к таймерам HAL позволяет сделать ОДИН системный вызов для создания оного, а не 5-10, если бы мы работали через inp()/outp() и сами бы подписывались на прерывания. В микроядерной архитектуре общение с драйверами происходит весьма затратно из-за того, что сами драйвера — это отдельные процессы. Поэтому, повторю, в такой архитектуре HAL делают именно "высокоабстрактным".

V>> Ибо в микроядерной архитектуре общение с драйверами происходит наиболее затратно,


VD>Во как? Кто тебе это сказал? Ты приписываешь микроядерной архитектуре проблемы современнх ОС и современных процессоров. В них процессы защищаются друг от друга аппоратно и имеются большие накладные расходы на комуникацию между процессами. Между тем в безопасной ОС без проблем можно сделать легкие процессы взаимодействующие в рамках одного адресного пространтсва. При этом снимаются ограничения скорости и идеи микрояденой архитектуры становятся очень даже приемлемыми.


Это ты про Сингулярити? Я где-то в других ветках уже задавался вопросом — а сколько приложений смогут работать в этой Сингулярити одновременно на 32-х битиной архитектуре? Аппаратная защита памяти реализует так же виртуальный механизм памяти. Весьма болезненно будет от него отказаться.

Опять же, unmanaged код при таком раскладе должен быть ЗАПРЕЩЕН как для драйверов, так и для пользовательских приложений. Поэтому в других ветках можешь начинать отвыкать повторять, что в C# есть unmanaged код "в случае чего".


V>> т.е. наличие лишнего драйвера дорогого стоит.


VD>Еще раз. Последий. Если я правильно понял суть исследования, то ребята делают максимально надежную ОС. В ней принципиально предпочитаются более надежные решения более быстрым. О скорости они конечно тоже думают, но уже во вторую очередь. Все драйверы в этой ос являются отдельными процессами. Никакой экономии драйверов не делается. Все процессы общаются между собой исключительно по средствам типизированных сообщений. Ну, а приемлемая скорость достигается тем, что процессы живут в одном адресном пространстве, а их память защищается применением типобезопасного языка и верификации кода.


Это мы и так уже знаем. Где-то здесь я по этому моменту уже проходился: http://www.rsdn.ru/Forum/Message.aspx?mid=1514609&amp;only=1
Автор: vdimas
Дата: 30.11.05
— в самом конце

Вопрос о "вместимости" единого адресного пространства по-прежнему актуален.

V>>Именно поэтому я и считаю, что для каждой новой железки для этой Сингулярити придется приличную часть НЕПЕРЕНОСИМОГО кода по-любому писать в unmanaged.



V>>Тут я кое-что ответил Синклеру, не хочу повторяться http://www.rsdn.ru/Forum/Message.aspx?mid=1494189&amp;only=1
Автор: vdimas
Дата: 18.11.05


VD>Там ровным счетом ни одного аргумента. Одни домыслы.


Там указания на конкретные DLL Win2000 и выше, которая юзает HAL. Так же просьба просмотреть наличие драйверов на основные системные устройства — их нет!!! (Или ты не удосужился проверить сам?) Домыслов нет, ты играешь "на публику" ИМХО.

V>>----------

V>>И по поводу моего незнания C#. А-я-яй опять дергать из контекста. Я говорил про прямой доступ не только к памяти, но и к портам и прерывания. Работа с прерываниями — это задание своих точек входа на обработчики. Я спрашивал — возможно ВСЕ это? НЕТ. На C# вряд ли можно написать корректную точку входа для обработки прерывания для конкретного проца. Т.е. в ф-ии HAL помимо всего того, что прочтешь по ссылке выше, надо будет добавлять нечто вроде SetStaticMethodAsIRQEntry, это тянет за собой еще одну проблему — надо обеспечить, чтобы указанный метод был явно загружен джитом, ибо обработка прерываний по сути должна иметь быструю реакцию, а не ждать, пока джит что-то там разджитит,

VD>Если бы ты вместо того чтобы упорно отстаивать свою совершенно не обоснованную позицию внимательно почитал бы то что пишут авторы ОС, то заметил бы, что ядро ОС работает на прекомпилированном машинном коде созданном компилятором Барток. Соотвественно никаких проблем джитом там нет и быть не может по определению.


Блин, ну при чем тут ядро, если речь о драйверах?
Да читали мы то что они пишут, не переживай. Насколько я понял, драйвера — это должны быть внешние сборки, которые можно будет динамически загружать/выгружать.

V>>т.е. в API надо добавлять еще методы по явному управлению VM (пусть даже во внутренние API OС).


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


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

V>>В общем, когда они дойдут до более-меннее реальной системы и откроют всю информацию по ней, тогда можно будет судить, что именно и где managed, а где нет.


VD>Правильно. А до тех пор все свои домыслы лучше держать при себе и просто верить тому, что говорят разработчики.


Фигушки. Не вчера родились и знаем, как легко жонглировать понятиями. Вон они даже понятие "процесс" переиначили. Без дополнительного разъяснения, что именно кроется за их "процессами" непонятна суть происходящего. Так что, извини, но оставляю за собой право критического взгляда на вещи и обмен мнениями на форумах.
Re[24]: С++ culture
От: vdimas Россия  
Дата: 05.12.05 09:59
Оценка:
Здравствуйте, VladD2, Вы писали:

Pzz>>NT никогда не была микроядерной ОС. Ядро НТ монолитно,


VD>Windows NT microkernel

VD>http://en.wikipedia.org/wiki/Windows_NT

А ты сам по найденым ссылкам ходил?

Microsoft hired a group of developers from Digital Equipment Corporation led by Dave Cutler to build Windows NT, and many elements reflect earlier DEC experience with VMS and RSX-11. The OS is designed to run on multiple instruction set architectures, with the kernel separated from the hardware by a hardware abstraction layer. APIs are implemented as subsystems atop the publicly undocumented Native API; it was this that allowed the late adoption of the Windows API. Originally a microkernel design, subsequent releases have integrated more functions into the kernel for better performance. Windows NT was the first operating system to use Unicode internally.


Неужели ты не знал, что в виндах можно писать kernel-mode дрова? Полностью микроядерной NT никогда не была. И как раз там же в википедии ответ на твой вопрос — "нафига HAL монолитным ОС". Как видишь, HAL и микроядро по-прежднему никак не связаны.
Re[22]: С++ culture
От: vdimas Россия  
Дата: 05.12.05 10:13
Оценка:
Здравствуйте, VladD2, Вы писали:

V>>Ориентируясь же на произвольную архитектуру необходимо операционке предоставить унифицированный доступ к этим фичам. Разумеется, не через inp() и outp(), а именно через более высокий абстрактный уровень.


VD>Да какая разница где и как будет реализовано абстрагирование от тонкостей аппаратуры? ... Синклер тебе верно заметил, что то что действительно не возможно вылевается в 2-3 функции работы с портами.


VD>А все остальное пишется с их использованием. Функции эти в общем-то примитивный и могут быть просто написаны в машинных кодах.


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

VD>Ты же ведь другое изначально утверждал. Ты утверждал, что невозможно на C# писать ОС так как он что-то там не может.


Да где? Опять за старое? Я утвержал, что если HAL будет высокоуровневый (и я сильно подозреваю, что именно так, а не как ты там говоришь про 3 машинные инструкции), то много кода надо писать как unmanaged. Если хочешь с чем-то спорить, то спорь именно с этим. Пока я ни одного нормального аргумента не увидел, кроме "надо верить на слово". Я и не спорю с ними, я дополняю их отчет размышлениями о доли "unmanaged" кода в их ОС. (Мое демократическое право )
Re[27]: С++ culture
От: vdimas Россия  
Дата: 05.12.05 10:16
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Что именно там от микроядра?


Присоединяюсь к вопросу.
Заодно очередное домашнее задание Владу Всезнающему. Написать простейший user-mode драйвер.
Re[25]: С++ culture
От: Pzz Россия https://github.com/alexpevzner
Дата: 05.12.05 10:53
Оценка:
vdimas wrote:
>
> Pzz>>NT никогда не была микроядерной ОС. Ядро НТ монолитно,
>
> VD>Windows NT microkernel
> <http://www.google.ru/search?hl=ru&amp;q=Windows+NT+microkernel&amp;lr=&gt;
> VD>http://en.wikipedia.org/wiki/Windows_NT
>
> А ты сам по найденым ссылкам ходил?
>
> Microsoft hired a group of developers from Digital Equipment Corporation
> led by Dave Cutler to build Windows NT, and many elements reflect
> earlier DEC experience with VMS and RSX-11. The OS is designed to run on
> multiple instruction set architectures, with the kernel separated from
> the hardware by a hardware abstraction layer. APIs are implemented as
> subsystems atop the publicly undocumented Native API; it was this that
> allowed the late adoption of the Windows API. *Originally a microkernel
> design, subsequent releases have integrated more functions into the
> kernel for better performance.* Windows NT was the first operating
> system to use Unicode internally.

Я читал этот текст.

> Неужели ты не знал, что в виндах можно писать kernel-mode дрова?

> Полностью микроядерной NT никогда не была. И как раз там же в википедии
> ответ на твой вопрос — "нафига HAL монолитным ОС". Как видишь, HAL и
> микроядро по-прежднему никак не связаны.

В смысле, user-mode drivers? И как же их писать?
Posted via RSDN NNTP Server 2.0
Re[25]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.12.05 19:04
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Неужели ты не знал, что в виндах можно писать kernel-mode дрова? Полностью микроядерной NT никогда не была. И как раз там же в википедии ответ на твой вопрос — "нафига HAL монолитным ОС". Как видишь, HAL и микроядро по-прежднему никак не связаны.


Я и не утвреждал, что NT имеет чистую микроядерную архитектуру. Я утверждал что она основана на идеях микроядерной архитектуры и постепенно сползала в монолитную сторону интегрируя в ядро все больше и больше кода. NT 3.x практически не имела такого кода. А в 4.0 его было уже выше крыши. Собственно это и сказано в приведенных ссылках.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.12.05 19:04
Оценка:
Здравствуйте, vdimas, Вы писали:

VD>>С чего бы это? Наоборот требуется минимальное ядро абстрагирующее от самых тонких вещей. Далее дрова работая через это микроядро абстрагируют ОС от остальных деталей реализации железа.


V>Блин, туго. Возьми для примера таймер. Сколько нужно приседаний, чтобы создать этот объект ядра? Причем эти приседания зависят от количества, способа обращения и интерпретации результатов работы внешних таймеров, а некоторые реализации вообще обходятся БЕЗ внешних аппаратных таймеров (в WinXX, в которых внешние таймеры задействованы для других нужд). Применительно к таймерам HAL позволяет сделать ОДИН системный вызов для создания оного, а не 5-10, если бы мы работали через inp()/outp() и сами бы подписывались на прерывания. В микроядерной архитектуре общение с драйверами происходит весьма затратно из-за того, что сами драйвера — это отдельные процессы. Поэтому, повторю, в такой архитектуре HAL делают именно "высокоабстрактным".


Да это уже не туго. Это уже тугоухо.

Читай по губам. Повторяю последний раз. В безопасной среде исполнения HAL может работать в том же кольце защиты, что и прикладные процессы. Защита памяти ведь не требуется, так как ни один процесс не может повредить чужие данные. При этом стоимость вызовов HAL-а фактически становится такой же как стоимость вызовов внутрепроцессных методов (а то и быстрее если учесть что и на этом уровне можно заниматься инлайнингом и оптимизациями).

По этому в такой архитектуре можно делать очень тонкий HAL, а все проблемы с таймерами и т.п. переносить в драйверы устройств работающий в отдельных процессах.

V>Это ты про Сингулярити?


А о чем по-твоему мы тут говорили? Ты же ее все время обсуждашь доказывая что все слова ее авторов невозможны.

V> Я где-то в других ветках уже задавался вопросом — а сколько приложений смогут работать в этой Сингулярити одновременно на 32-х битиной архитектуре? Аппаратная защита памяти реализует так же виртуальный механизм памяти. Весьма болезненно будет от него отказаться.


Ага колосальная проблема. Ведь на сегодны все серверы забиты 5 и более гигами памяти, а 64-битных процессоров не видно даже в подзорную трубу. Согласен. Надо будет ее обсудеть... в "Колегах".

V>Опять же, unmanaged код при таком раскладе должен быть ЗАПРЕЩЕН как для драйверов, так и для пользовательских приложений. Поэтому в других ветках можешь начинать отвыкать повторять, что в C# есть unmanaged код "в случае чего".


Насколько я понял прикладные процессы в Сингулярити приципиально обязаны быть безопасными. Ну, а небезопасные возможности C# можно использовать внутри ОС для повышения быстродействия и замены С/С++.

Ну, а анменеджед-код на C# вообще создать невозможно, если конечно не брать в рассчет возможность сформировать машинный код побайтно. Ты очередной раз путашь термины "анменеджед" и "ансэйф".

VD>>Если бы ты вместо того чтобы упорно отстаивать свою совершенно не обоснованную позицию внимательно почитал бы то что пишут авторы ОС, то заметил бы, что ядро ОС работает на прекомпилированном машинном коде созданном компилятором Барток. Соотвественно никаких проблем джитом там нет и быть не может по определению.


V>Блин, ну при чем тут ядро, если речь о драйверах?


А что мешает драйвер прекомпилировать перед запуском? Если уж есть просто отдельный компилятор...

V>Да читали мы то что они пишут, не переживай. Насколько я понял, драйвера — это должны быть внешние сборки, которые можно будет динамически загружать/выгружать.


Это без разницы. Внешние сборки тоже в лучшем виде прекомпилируются. Это можно делать даже на первой версии дотнета.

V>По-твоему, мы не можем обсуждать отдельные моменты? Мне интересны именно технические детали. До твоего рантайма еще доберемся, никуда он не денется. Когда сами разработчики будут готовы.


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


V>Фигушки. Не вчера родились и знаем, как легко жонглировать понятиями. Вон они даже понятие "процесс" переиначили.


Это чем же это? Я бы еще понял если бы ты подискутировал с функциональциками которые рассказывают о процессах в Эрленг. Но тут... ?

V> Без дополнительного разъяснения, что именно кроется за их "процессами" непонятна суть происходящего. Так что, извини, но оставляю за собой право критического взгляда на вещи и обмен мнениями на форумах.


Оставляй конечно. Но тогда хоть аргументируй. А то я вижу одни догмы. Вроде как обсуждаешь управляемую ОС, а все скатывашся на обсуждение проблем ОС где защита делается на базе аппаратной защиты памяти и т.п.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.12.05 19:04
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Да где? Опять за старое?


За что за старое? Это ты за старое. Уже отказывашся от своих же слов. Не ты ли тут твердил, что нужно много писать на С/С++? Нахрена, объясни мне, нужны вообще С/++? Что нельзя сделать в небезопасном режиме Шарпа?

V> Я утвержал, что если HAL будет высокоуровневый (и я сильно подозреваю, что именно так, а не как ты там говоришь про 3 машинные инструкции), то много кода надо писать как unmanaged.


Ты уже задолбал. На Ченел9 раз двадцать было сказано, что почти все написано на C#, что С++ и т.п. использован в очень редких случаях типа стартап-кода который работает в реальном режиме процессора, что основная масса кода ОС — это безопасный код, что на ансэйфе в основном встречается в реализации ЖЦ.

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

V> Если хочешь с чем-то спорить, то спорь именно с этим.


Это ты с чем-то хочешь спорить. Мне лично все ясно. Ситуация проще паренной репы. Ты просто не можешь свыкнуться с мыслью, что то что ты считал только что невозможным, более чем возможно.

V> Пока я ни одного нормального аргумента не увидел, кроме "надо верить на слово". Я и не спорю с ними, я дополняю их отчет размышлениями о доли "unmanaged" кода в их ОС. (Мое демократическое право )


А не надо дополнять чужие утверждения своими домыслами.

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

ЗЫ

Ну, и хорошо бы чтобы ты перестал путать термины ансэйф и анменеджед. C# принципиально не может породить анменеджед-код. Он может работать с анменеджед-дканными в ансэйф-режиме.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: С++ culture
От: Pzz Россия https://github.com/alexpevzner
Дата: 05.12.05 19:18
Оценка:
VladD2 wrote:
>
> V>Неужели ты не знал, что в виндах можно писать kernel-mode дрова?
> Полностью микроядерной NT никогда не была. И как раз там же в википедии
> ответ на твой вопрос — "нафига HAL монолитным ОС". Как видишь, HAL и
> микроядро по-прежднему никак не связаны.
>
> Я и не утвреждал, что NT имеет чистую микроядерную архитектуру. Я
> утверждал что она основана на идеях микроядерной архитектуры и
> постепенно сползала в монолитную сторону интегрируя в ядро все больше и
> больше кода. NT 3.x практически не имела такого кода. А в 4.0 его было
> уже выше крыши. Собственно это и сказано в приведенных ссылках.

Прошу прощения за занудливость, но все же, на каких именно идеях
микроядерной архитектуры идеях была основана NT?
Posted via RSDN NNTP Server 2.0
Re[24]: С++ culture
От: vdimas Россия  
Дата: 07.12.05 10:24
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, vdimas, Вы писали:


VD>За что за старое? Это ты за старое. Уже отказывашся от своих же слов. Не ты ли тут твердил, что нужно много писать на С/С++? Нахрена, объясни мне, нужны вообще С/++? Что нельзя сделать в небезопасном режиме Шарпа?


Я поднялся высоко по ветке и вот тот мой кусок, с которорым ты не согласился:

Может программа на C# непосредственно обращаться к портам ввода/вывода? или по фиксированным адресам памяти? Или настраивать внутренние регистры процессора на новые карты отображения виртуальных устройств ввода/вывода? НЕТ. И никогда не сможет by design. Очевидно, надо на ASM/C/C++ написать требуемый функционал, и приподнести его "на блюдечке" управляемой среде в виде простых интерфейсов. Реально это? Вполне.


Мне пофиг какой там язык будет (ASM/C/C++) или твой Барток (или как его там). Я говорил о невозможности сделать часть задач на C#, пользуясь своими знаниями об этом языке.

А вот твое выше (ты отвечал mrozov):

Кстати, ты все же ошибашся. Есть таки очень разумные и весьма дальновидные люди которые пишут драйверы на C#.


Ты про драйверы, я же сделал замечание про ядро. Если тебе не понравились мои примеры (ASM/C/C++), то уж извини — я не зря не уточнил, т.к. не могу знать подробности. Мне вообще-то все-равно, на чем это будет написано, но это должен быть язык, который позволяет ЭТО написать, и который уж никак не может быть использован для пользовательских приложений этой же ОС.

V>> Я утвержал, что если HAL будет высокоуровневый (и я сильно подозреваю, что именно так, а не как ты там говоришь про 3 машинные инструкции), то много кода надо писать как unmanaged.


VD>На Ченел9 раз двадцать было сказано, что почти все написано на C#, что С++ и т.п. использован в очень редких случаях типа стартап-кода который работает в реальном режиме процессора, что основная масса кода ОС — это безопасный код, что на ансэйфе в основном встречается в реализации ЖЦ.


VD>Это ты с чем-то хочешь спорить. Мне лично все ясно. Ситуация проще паренной репы. Ты просто не можешь свыкнуться с мыслью, что то что ты считал только что невозможным, более чем возможно.


Я тебе привел свою цитату из начала обсуждения. Не помню, чтобы я чего-то там не считал невозможным. Я обсуждаю долю unmanaged кода. Заодно unsafe (спасибо за поправки).

Вроде мы пришли уже к тому, что в их драйверах никакого unsafe и близко быть не может из-за плоской модели памяти самой ОС. (Кстати, в "плоском" режиме даже ввод/вывод происходит гораздо эффективней, так что, кое-какие бенефиты от плоской модели разумеется есть.)

VD>Ну, и хорошо бы чтобы ты перестал путать термины ансэйф и анменеджед. C# принципиально не может породить анменеджед-код. Он может работать с анменеджед-дканными в ансэйф-режиме.


Я говорил имено про unmanaged код в том первом абзаце. В принципе, если ты напираешь на "дыру" в С++ в виде возможности произвольной реинтерпретации памяти в С++, то твой unsafe позволяет точно такое же.

--------
Кстати, насчет моих "или по фиксированным адресам памяти?". Ты там позже прошелся по этой фразе, что я недостаточно знаю C# раз такое написал. Прочитай в той же фразе чуть дальше. Имелась ввиду фиксированная "плоская" память и реализация механизма виртуального режима (суть его одинакова как для портов так и для памяти). Насчет работы Сингулярити в едином адресном пространстве я прочел уже позже.
Re[24]: С++ culture
От: vdimas Россия  
Дата: 07.12.05 10:45
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Читай по губам. Повторяю последний раз. В безопасной среде исполнения HAL может работать в том же кольце защиты, что и прикладные процессы. Защита памяти ведь не требуется, так как ни один процесс не может повредить чужие данные. При этом стоимость вызовов HAL-а фактически становится такой же как стоимость вызовов внутрепроцессных методов (а то и быстрее если учесть что и на этом уровне можно заниматься инлайнингом и оптимизациями).


VD>По этому в такой архитектуре можно делать очень тонкий HAL, а все проблемы с таймерами и т.п. переносить в драйверы устройств работающий в отдельных процессах.


Браво, начал с того, что стал доказывать, что HAL присущь только микроядерной архитектуре, закончил своими предположениями по поводу того, как это работает в Сингулярити. Браво. Но сначала согласись, что не понимал роль HAL в произвольных архитектурах.

Конкретно по твоему вопросу. Ставлю 5 баксов, что таймер они все-таки включат в HAL а не в драйвер, невзирая на легкость вызова в среде единого адресного пространства

Есть такая фигня как целессобразность, я почему-то уверен, что разработчики обсуждаемого сабжа этим понятием пренебрегать не станут.


V>> Я где-то в других ветках уже задавался вопросом — а сколько приложений смогут работать в этой Сингулярити одновременно на 32-х битиной архитектуре? Аппаратная защита памяти реализует так же виртуальный механизм памяти. Весьма болезненно будет от него отказаться.


VD>Ага колосальная проблема. Ведь на сегодны все серверы забиты 5 и более гигами памяти, а 64-битных процессоров не видно даже в подзорную трубу. Согласен. Надо будет ее обсудеть... в "Колегах".


Обсуди. У меня в студии плагины типа Решарпера + Rational XDE + весьма большие проекты. В общем, 2-3 студии с разными солюшинами открыл и 2 гига памяти под завязку. А когда отлаживаешь работу дизайнеров в этих же проектах (т.е. запускаешь саму студию как процесс для отладки), и используешь отладку unmanaged+managed — то вообще труба.


VD>Насколько я понял прикладные процессы в Сингулярити приципиально обязаны быть безопасными.


Т.е. и драйверы тоже, правда же?

VD>Ну, а небезопасные возможности C# можно использовать внутри ОС для повышения быстродействия и замены С/С++.



V>>Да читали мы то что они пишут, не переживай. Насколько я понял, драйвера — это должны быть внешние сборки, которые можно будет динамически загружать/выгружать.


VD>Это без разницы. Внешние сборки тоже в лучшем виде прекомпилируются. Это можно делать даже на первой версии дотнета.


OK, здесь действительно возможны решения (насчет pre-JIT).

VD>Оставляй конечно. Но тогда хоть аргументируй. А то я вижу одни догмы. Вроде как обсуждаешь управляемую ОС, а все скатывашся на обсуждение проблем ОС где защита делается на базе аппаратной защиты памяти и т.п.


Вообще-то мы "зацепились" после моего предположения, что с их концепцией им потребуется довольно высокая абстракция от железки, т.е. некий приличный базис "unsafe" должен будет существовать для конкретной железки.

Почему я делаю такое предположение? Глядя на происходящее в мире Java-встраиваемых устройств. Речь идет о переносимости, причем переносимости не только пользовательстких приложений, но и кода самой ОС (который немаленький).

Стараться сделать ВСЕСЬ КОД ЯДРА управляемым элементарно НЕЦЕЛЕСООБРАЗНО (т.е. опуститься до уровня inp()/outp() и не выше). Опускание на такой уровень абсолютно ничего не дает управляемой ОС, чей фокус заострен все-таки на немного других моментах. После прочтения последних их отчетов (до этого последний раз читал более полугода назад), мне кажется, что я скорее прав, чем нет.
Re[27]: С++ culture
От: vdimas Россия  
Дата: 07.12.05 10:45
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Прошу прощения за занудливость, но все же, на каких именно идеях

Pzz>микроядерной архитектуры идеях была основана NT?

У меня все больше складывается ощущение, что участники беседы по-разному представляют себе цели и задачи выполняемые ядром, подчас путая ядро с самой ОС. Попытка связать микроядерную архитектуру с HAL — показательный пример.

Речь шла о драйверах. Драйверы — не являются частью ядра ОС (!!! даже монолитной, не спешим возражать — идем далее). Драйвер — это ПО адаптации устройства к некоему универсальному АПИ (обычно, "внутреннему" АПИ ОС). Соответственно, драйвер может относится к чему угодно, к подсистеме ввода/вывода, например (чаще всего).

Откуда возникла путаница понятий "ядра" и "вообще всей ОС"? Из-за системы защиты памяти, реализованной на большинстве современных процессоров. Многие подсистемы ОС: ввода/вывода, планировщик, сситема управления виртуальной памятью, системы мониторинга и даже загрузчик (!!!) выполняются на некоем уровне исполнения (с т.з. терминов конкретного процессора), на котором выполняется и ядро ОС. Непонятно с чей легкой руки, механизм исполнения на уровне ядра стали отождествлять с самим ядром. Задача ядра ОС — это координация подсистем ОС. Даже за запуск/поддержание/уничтожение пользовательских процессов отвечают сразу несколько подсистем, которые традиционно не относят к ядру (я уже молчу об оконной системе виндов, которая развалила ту саму микроядерную архитектуру NT, странно, что здесь сразу не ответили на этот вопрос — что именно нарушило первоначальные микроядерные задумки в NT? Быстродействие тогдашних железок банально все нарушило и оконную подсистему впихнули в низкий уровень исполнения... а затем пошло-поехало и туда же впихнули все что могли ).

Попытки упростить "внутренее" АПИ ОС привели к идее микроядра. Суть — сделать "внутреннее" АПИ ядра открытым, минимальным, а значит предоставить возможность более легкого и независимого развития остальных подсистем ОС. Однако, за это приходится платить, а именно — защищать само ядро ОС. Какой набор подсистем ОС все-таки будет исполняться в "процессе" ядра (если слово "процесс" вообще применимо здесь) в микроядерной архитектуре? Это, разумеется, не специфируется, оставлено на усмотрение разработчиков. Остальные подсистемы работают в процессах за барьером механизма защищенной/виртуальной памяти.

Именно описанную хрень и обозвали "микроядром". Если в Сингулярити ядро и сами их т.н. "процессы" работают в едином адресном пространстве, то понятие "микроядра" здесь как-то не клеится. Давайте назовем это "слоеным ПО", будет ближе. Насколько я понял, Влад приписал наличие микроядра этой ОС из-за того, что встретил упоминание об использовании HAL там же (вот курьез ) В сочетании с собственным представлением о HAL как об аттрибуттике именно микроядерной архитектуры сделал такой странный вывод, ИМХО.
Re[28]: С++ culture
От: Pzz Россия https://github.com/alexpevzner
Дата: 08.12.05 00:51
Оценка:
vdimas wrote:
>
> Откуда возникла путаница понятий "ядра" и "вообще всей ОС"? Из-за
> системы защиты памяти, реализованной на большинстве современных
> процессоров. Многие подсистемы ОС: ввода/вывода, планировщик, сситема
> управления виртуальной памятью, системы мониторинга и даже загрузчик
> (!!!) *выполняются* на некоем уровне исполнения (с т.з. терминов
> конкретного процессора), на котором выполняется и ядро ОС. Непонятно с
> чей легкой руки, механизм исполнения на уровне ядра стали отождествлять
> с самим ядром. Задача ядра ОС — это координация подсистем ОС. Даже за

Хорошо, давай попробуем определить понятие ядра.

Я предлагаю примерно следующее определение:
1. Программой называется совокупность кода и данных, размещающиеся в
процессе выполнения в едином адресном пространстве.
2. "Самая главная" программа называется ядром.

В этом смысле, драйвера в традиционных ОС все же часть ядра. А
прикладные программы — нет. ОС состоит не только из ядра, но и
некоторого набора прикладных программ.

То, что драйвера от ядра как-бы отделены, не делают их не частью ядра.
Не надо путать модульность с микроядерностью.

> запуск/поддержание/уничтожение пользовательских процессов отвечают сразу

> несколько подсистем, которые традиционно не относят к ядру (/я уже молчу
> об оконной системе виндов, которая развалила ту саму микроядерную
> архитектуру NT, странно, что здесь сразу не ответили на этот вопрос —
> что именно нарушило первоначальные микроядерные задумки в NT?
> Быстродействие тогдашних железок банально все нарушило и оконную
> подсистему впихнули в низкий уровень исполнения... а затем пошло-поехало
> и туда же впихнули все что могли / ).

Так все же, в чем заключается микроядерность NT? Не путаем ли мы ее с
модульностью?

> Попытки упростить "внутренее" АПИ ОС привели к идее микроядра. Суть —

> сделать "внутреннее" АПИ ядра открытым, минимальным, а значит
> предоставить возможность более легкого и независимого развития остальных
> подсистем ОС. Однако, за это приходится платить, а именно — защищать
> само ядро ОС. Какой набор подсистем ОС все-таки будет исполняться в
> "процессе" ядра (если слово "процесс" вообще применимо здесь) в
> микроядерной архитектуре? Это, разумеется, не специфируется, оставлено
> на усмотрение разработчиков. Остальные подсистемы работают в процессах
> за барьером механизма защищенной/виртуальной памяти.

Важно скорее не наличие механизма защиты памяти, а наличие у програм
собственного контекста исполнения.

Пример minix — микроядерная ОС для 16-битного 8086, где никакой защиты
памяти вообще не было предусмотрено.

У minix'а, кстати, по-моему нет HAL'а
Posted via RSDN NNTP Server 2.0
Re[25]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.05 02:38
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Браво, начал с того, что стал доказывать, что HAL присущь только микроядерной архитектуре, закончил своими предположениями по поводу того, как это работает в Сингулярити. Браво. Но сначала согласись, что не понимал роль HAL в произвольных архитектурах.


Микроядро это и есть ХАЛ. Что до предположений, то ты только ими и сыплешь.

V>Конкретно по твоему вопросу. Ставлю 5 баксов, что таймер они все-таки включат в HAL а не в драйвер, невзирая на легкость вызова в среде единого адресного пространства


Нда, серьезные деньгий.

V>Есть такая фигня как целессобразность, я почему-то уверен, что разработчики обсуждаемого сабжа этим понятием пренебрегать не станут.


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

VD>>Ага колосальная проблема. Ведь на сегодны все серверы забиты 5 и более гигами памяти, а 64-битных процессоров не видно даже в подзорную трубу. Согласен. Надо будет ее обсудеть... в "Колегах".


V>Обсуди. У меня в студии плагины типа Решарпера + Rational XDE + весьма большие проекты. В общем, 2-3 студии с разными солюшинами открыл и 2 гига памяти под завязку.


У меня постоянно 3-5 студий и никаких проблем в 1 гиге. При этом еще куча софта, а память около 600 метров отедено. РеШарпера правда нет. Он глючит еще, а мне и того что есть хватает. Но это все лирика.

А правда жизни такая. Памяти у меня 1 гиг. Процессор у меня АМД 64. Так что проблем с 10 и более гигами не будет. Были бы они нужны. К тому же времени когда ОС вроде Сингулярити решатся пустить на поток, ну, в смысле, использовать ее как пилотную, но все же коммерческую ОС, пройдет еще лет 5-10 и компов без 10 гиг и не с 64-битной архитектурой просто не будет. Так что это не вопрос.

Если же сделать менее прожерливый ЖЦ, то глядишь можно будет даже сэкономить на памяти.

V> А когда отлаживаешь работу дизайнеров в этих же проектах (т.е. запускаешь саму студию как процесс для отладки), и используешь отладку unmanaged+managed — то вообще труба.


Может у тебя с ХДЕ проблемы?

VD>>Насколько я понял прикладные процессы в Сингулярити приципиально обязаны быть безопасными.


V>Т.е. и драйверы тоже, правда же?


Да. Но само ядро может содержать небезопасный код. Тот же ансэйф шарповский проходит на ура. Так что особо тонкие места общения с железом можно будет оптимизировать. Вроде как ЖЦ использует ансэйф-код.

V>OK, здесь действительно возможны решения (насчет pre-JIT).


И я о том же. А у них в руках Барток — оптимизирующий компилятор из исил-а в машинный код. Так что это у них уже есть.

V>Вообще-то мы "зацепились" после моего предположения, что с их концепцией им потребуется довольно высокая абстракция от железки, т.е. некий приличный базис "unsafe" должен будет существовать для конкретной железки.


Вопрос сколько того ансэйфа. Согласен, что для доступа к портам, ДМА, прерываниям и реализации ЖЦ им без ансэфа будет туго. Но это если код минимизировать не так уж много. Темболее, что ансэйф != анменеджед, т.е. 80% кода все же будет безопастным, а опасные куски будут все в коде как на ладони и их проконтролировать будет не сложно.

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

V>Почему я делаю такое предположение? Глядя на происходящее в мире Java-встраиваемых устройств. Речь идет о переносимости, причем переносимости не только пользовательстких приложений, но и кода самой ОС (который немаленький).


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

V>Стараться сделать ВСЕСЬ КОД ЯДРА управляемым элементарно НЕЦЕЛЕСООБРАЗНО (т.е. опуститься до уровня inp()/outp() и не выше).


Ну, этот уровень это уже неплохо. Согласись! К тому же что говорить о чем-то в разрезе предположений когда есть четкие заявления, что в ОС даже ансэйф применяется в очень ограниченных количествах, а все драва исключительно безопасные (в том числе и драйвер консоли/видюхи).

V> Опускание на такой уровень абсолютно ничего не дает управляемой ОС, чей фокус заострен все-таки на немного других моментах. После прочтения последних их отчетов (до этого последний раз читал более полугода назад), мне кажется, что я скорее прав, чем нет.


Ну, мне кажется что скрее неправ. Тут скорее другая проблема будет. ОС может оказаться медленной относительно традиционных. Они слишком подчеркивают, что не производительность для них не главное. Ну, да исследования не делаются ради получения работающего результата. Важнее получаемые данные. В конечной ОС возможно будет учтен опыт и Синкулярити и традиционных микроядерных ОС вроде БСД и в итоге получится очередной гибрид, но на новом уровене. По крайней мере хочется в это верить, так как сегоднящние NT и Линкус — это дырявые колоши с доисторической архитекрутрой.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.05 02:38
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Мне пофиг какой там язык будет (ASM/C/C++) или твой Барток (или как его там). Я говорил о невозможности сделать часть задач на C#, пользуясь своими знаниями об этом языке.


Может тебе и пофигу. Но нет ни одной задачи которую можно решить на С и нельзя на Шарпе. Что до асма, то мы с тобой вроде сошлись на мнении, что его можно оставить в микроскопических количествах, а то и просто заменить бинарными кусками написанными в маш.кодах. Думаю понятно, что чем меньше анменеджед-кода и ансэйфа тем предсказуемее и надженее будет ОС. В конце концов насколько я понимаю, ХАЛ то й же NT тоже на ассемблере нибусь написан.

V>А вот твое выше (ты отвечал mrozov):

V>

V>Кстати, ты все же ошибашся. Есть таки очень разумные и весьма дальновидные люди которые пишут драйверы на C#.


V>Ты про драйверы, я же сделал замечание про ядро. Если тебе не понравились мои примеры (ASM/C/C++), то уж извини — я не зря не уточнил, т.к. не могу знать подробности. Мне вообще-то все-равно, на чем это будет написано, но это должен быть язык, который позволяет ЭТО написать, и который уж никак не может быть использован для пользовательских приложений этой же ОС.


Единственный язык позволяющий обращаться к портам без библиотек — это ассемблер. Хотя я уже повторяюсь. Потому и не понравилось.

V>Я тебе привел свою цитату из начала обсуждения. Не помню, чтобы я чего-то там не считал невозможным. Я обсуждаю долю unmanaged кода. Заодно unsafe (спасибо за поправки).


А ты вот это читал ftp://ftp.research.microsoft.com/pub/tr/TR-2005-135.pdf ?

Code in Singularity is either verified or trusted. Verified code’s type and memory safety is
checked by a compiler. Unverifiable code must be trusted by the system and is limited to the
hardware abstraction layer (HAL), kernel, and parts of the run-time system. Most of the kernel is
verifiably safe
, but portions are written in assembler, C++, and unsafe C#.
All other code is written in a safe language, translated to safe Microsoft Intermediate
Language (MSIL)4, and then compiled to x86 by the Bartok compiler [20]. Currently, we trust
that Bartok correctly verifies and generates safe code. This is obviously unsatisfactory in the long
run and we plan to use typed assembly language to verify the output of the compiler and reduce
this part of the trusted computing base to a small verifier [36]


V>Вроде мы пришли уже к тому, что в их драйверах никакого unsafe и близко быть не может из-за плоской модели памяти самой ОС. (Кстати, в "плоском" режиме даже ввод/вывод происходит гораздо эффективней, так что, кое-какие бенефиты от плоской модели разумеется есть.)


Кстати, при всем при том, что они говорят о защите на уровне безоспасного кода... все же они же говорят и о страничной подкачке. Это уже и в мою буйную на фантазию голову войти не может.

В общем, нужно читать этот документ. Он вроде как многое проясняет.

V>Я говорил имено про unmanaged код в том первом абзаце. В принципе, если ты напираешь на "дыру" в С++ в виде возможности произвольной реинтерпретации памяти в С++, то твой unsafe позволяет точно такое же.


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

V>--------

V>Кстати, насчет моих "или по фиксированным адресам памяти?". Ты там позже прошелся по этой фразе, что я недостаточно знаю C# раз такое написал. Прочитай в той же фразе чуть дальше. Имелась ввиду фиксированная "плоская" память и реализация механизма виртуального режима (суть его одинакова как для портов так и для памяти). Насчет работы Сингулярити в едином адресном пространстве я прочел уже позже.

А я тебе про это сразу говорил. Я это поня еще до того как они это явно сказали. Ну, просто все что они наобещали практически не реально без единого адрессного пространства. Да и нахрена связываться с безопасным кодом если защита аппаратная. Сделать сторую БСД не виликого ума дела. Это, на сегодны, работа не для ученых, а для очень хороших инжинеров/программистов. Собсвтенно идеи витают в воздухе нужно только приложить несколько светлых голов и много моного пошлых баксов.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: С++ culture
От: srggal Украина  
Дата: 14.12.05 12:39
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ничего она не повторяет. Там сказано то что было на самом деле. ОС проектировалась как микроядерная, но в ходе разработки в ядро засовавались все большие и большие куски тем самым уводя ОС в сторону монолитных. На сегодня это гибрид.


ГМ пропустил много интересного, как я вижу.

микроядро + засовывание_в_ядровсего_что_ни_попадя = гибрид

Ок, это верно.

Именно Такие гибриды и называются монолитным ядром.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[10]: С++ culture
От: Pavel Chikulaev Россия  
Дата: 15.12.05 11:27
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>А что собственно "бррр"? И тем более чем не угодил первый вариант? И наконец, может есть третий вариант, который лучше их обоих?


using 
(
    MyRAII1 r1 = new MyRAII1(),
    MyRAII2 r2 = new MyRAII2(),
    MyRAII3 r3 = new MyRAII3(),
    MyRAII4 r4 = new MyRAII4()
)
{
}

Согласно ECMA 334 (15.13). Но С++ лучше всех Однозначно.
Re[29]: С++ culture
От: vdimas Россия  
Дата: 06.01.06 14:08
Оценка:
Здравствуйте, Pzz, Вы писали:

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

Сама ОС состоит из множества компонент. Ядро — это лишь одна из компонент. Назначение ядра — связать остальные подсистемы ОС. Например, в пакетных ОС основной алгоритм — это как раз бесконечный цикл ядра ОС, который последовательно вызывал планировщик, а затем задачи спланированного пакетаи т.д. бесконечно.

В многозадачных "выталкивающих" ОС этот алгоритм изменился не сильно, но теперь управляется прерываниями. Однако суть все та же — бесконечный цикл, в котором вызывается планировщик и затем выделяется квант выбранному процессу.

В классике именно этот основной цикл, и все, что связано с его обслуживанием и зовется ядром. Ни сам шедуллер ни подсистемы ввода/вывода к нему не относятся.

Далее. Драйвера. Я уверен, что мне трудно будет убедить не рассматривать понятие "драйвер" так, как это делается в WinNT или Linux. Понятие драйвер не имеет ничего общего ни с HAL, ни с ядром. И даже тот факт, что драйвера WinNT работают на уровне ядра — это всего лишь очень частный пример реализации драйверов. На самом деле не существует каких-либо требований на "единственность" АПИ драйверов в конкретной ОС. В WinNT имеющеся АПИ, доступное через DDK — это АПИ для драйверов, предназначенных для работы на уровне ядра. Однако, у тебя нет абсолютно никаких ограничений на разработку драйверов пользовательского уровня. Обрати на эти факты внимание.

Далее. Еще один важный момент. Ввод/вывод. Так уж получилось, что качественный шедуллинг в "выталкивающих" многозадачных ОС невозможен без учета состояний подсистем ввода/вывода. Т.е., само ядро должно знать о том, что приложение находится в ожидании и не переключать на него напрасно управление, ибо это дорогого стоит в системах с аппаратной защитой памяти. Т.е. я опять обращаю внимание на компроммиссы и перекосы в толкованиях терминов, внесенные в результате разработке ОСей, основанных на аппаратной защите памяти.

Далее все должно быть уже более понятно. Подавляющая масса драйверов — это драйвера ввода/вывода. В ОС типа WinNT вынужденно эти драйвера запихивают на системный уровень исполнения. Поэтому и сформировалось мнение, что драйвер — часть ядра (в большинстве ОС). Дудки, даже в WinNT — это просто модуль, который исполняется на уровне ядра, но это не значит, что является его частью.
Re[30]: С++ culture
От: Pzz Россия https://github.com/alexpevzner
Дата: 06.01.06 14:35
Оценка:
vdimas wrote:
>
> Сорри за запоздалый ответ.
> В общем, все немного не так, несмотря на то, что мне понятны рассуждения.

Насколько я помню, спор шел о том, является ли NT микроядерной системой.

> Далее. Драйвера. Я уверен, что мне трудно будет убедить не рассматривать

> понятие "драйвер" так, как это делается в WinNT или Linux. Понятие
> драйвер не имеет ничего общего ни с HAL, ни с ядром. И даже тот факт,
> что драйвера WinNT работают на уровне ядра — это всего лишь очень
> частный пример реализации драйверов. На самом деле не существует
> каких-либо требований на "единственность" АПИ драйверов в конкретной ОС.
> В WinNT имеющеся АПИ, доступное через DDK — это АПИ для драйверов,
> предназначенных для работы на уровне ядра. Однако, у тебя нет абсолютно
> никаких ограничений на разработку драйверов пользовательского уровня.
> Обрати на эти факты внимание.

Я согласен с тем, что возможна архитектура ОС, в которой драйвера не
являются частью ядра. Собственно, любая микроядерная ОС так устроена.

Однако в Виндовсе это не так. В Виндовсе "драйвер" можно рассматривать
как одно из двух:
1) компонент, который имеет доступ к ядерному API
2) компонент, который может создать DEVICE_OBJECT

Ни то не другое не возможно в Виндовсе из user space. И то и другое
требует исполнения в контексте ядра. Поэтому, все же, драйвера в Windows
— часть ядра, а не самостоятельные сущности. И тем самым, Windows не
микроядерная ОС (по-моему, спор шел именно об этом).

> Далее. Еще один важный момент. Ввод/вывод. Так уж получилось, что

> качественный шедуллинг в "выталкивающих" многозадачных ОС невозможен без
> учета состояний подсистем ввода/вывода. Т.е., само ядро должно знать о
> том, что приложение находится в ожидании и не переключать на него
> напрасно управление, ибо это дорогого стоит в системах с аппаратной
> защитой памяти. Т.е. я опять обращаю внимание на компроммиссы и перекосы
> в толкованиях терминов, внесенные в результате разработке ОСей,
> основанных на аппаратной защите памяти.

Scheduller'у, по большому счету, ничего не надо знать про ввод-вывод.
Ему надо знать только про примитивы синхронизации/ожидания.

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

> Далее все должно быть уже более понятно. Подавляющая масса драйверов —

> это драйвера ввода/вывода. В ОС типа WinNT вынужденно эти драйвера
> запихивают на системный уровень исполнения. Поэтому и сформировалось
> мнение, что драйвер — часть ядра (в большинстве ОС). Дудки, даже в WinNT
> — это просто модуль, который *исполняется *на уровне ядра, но это не
> значит, что является его частью.

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

Но в общем, это не важно. Я хочу сказать, что между Windows и UNIX нет
содержательной разницы в том, как ядро соотносится с драйверами. Поэтому
нельзя, пользуясь одними и теми же аргументами, утверждать, что Windows
— микроядерная система, а UNIX — нет.
Posted via RSDN NNTP Server 2.0
Re[29]: С++ culture
От: vdimas Россия  
Дата: 08.01.06 05:29
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Пример minix — микроядерная ОС для 16-битного 8086, где никакой защиты

Pzz>памяти вообще не было предусмотрено.

Pzz>У minix'а, кстати, по-моему нет HAL'а


А зачем ей HAL? Априори, если ОС ориентируется на конкретную аппаратную платформу и фиксированное окружение, то всякие абстракции ей и на фиг не сдались.

И зачем вообще повторять ошибку Влада и пытаться связать микроядерность и HAL? У любой абстракции может быть только одна причина — требование той самой абстракции.
Re[31]: С++ culture
От: vdimas Россия  
Дата: 08.01.06 05:34
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Если что-то исполняется на уровне ядра, работает в контексте ядра,

Pzz>располагается в адресном пространстве ядра и т.п., то по-моему, это
Pzz>часть ядра

И опять мы упорно навязываем частный случай общим понятиям. Забудь про контекст исполнения и адресное пространство. Вспомни, что полно железок и ОСей с единым адресным пространством. Следуя твоей логике, любое прикладное приложение в таких системах является частью ядра. Блин, ну как вообще можно пытаться проводить границы в ПО по физическим принципам? Это уже даже не смешно.
Re[26]: С++ culture
От: vdimas Россия  
Дата: 08.01.06 06:11
Оценка:
Здравствуйте, VladD2, Вы писали:


V>>Обсуди. У меня в студии плагины типа Решарпера + Rational XDE + весьма большие проекты. В общем, 2-3 студии с разными солюшинами открыл и 2 гига памяти под завязку.


VD>У меня постоянно 3-5 студий и никаких проблем в 1 гиге. При этом еще куча софта, а память около 600 метров отедено. РеШарпера правда нет. Он глючит еще, а мне и того что есть хватает.


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


VD>Может у тебя с ХДЕ проблемы?


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


VD>>>Насколько я понял прикладные процессы в Сингулярити приципиально обязаны быть безопасными.


V>>Т.е. и драйверы тоже, правда же?


VD>Да. Но само ядро может содержать небезопасный код. Тот же ансэйф шарповский проходит на ура. Так что особо тонкие места общения с железом можно будет оптимизировать.


Вот не могу добиться уточнения твоей т.з. на этот момент. Еще раз. Unsafe код в Сингулярити допустим только внутри "пояса безопасности". В этот пояс безопасности входит только сама VM и микроядро. Драйвера НЕ МОГУТ содержать небезопасный код. И мне уже прямо сейчас нетерпиться узнать, пойдут они на компроммиссы или нет к моменту выпуска коммерчесского варианта. Невзирая на мощность техники к тому моменту. А тож блин опять введут нечто вроде: "подписанный unsafe-драйвер", и будет всем смешно.


VD>Вроде как ЖЦ использует ансэйф-код.


Разумеется. Он же памятью оперирует.


V>>Вообще-то мы "зацепились" после моего предположения, что с их концепцией им потребуется довольно высокая абстракция от железки, т.е. некий приличный базис "unsafe" должен будет существовать для конкретной железки.


VD>Вопрос сколько того ансэйфа. Согласен, что для доступа к портам, ДМА, прерываниям и реализации ЖЦ им без ансэфа будет туго. Но это если код минимизировать не так уж много. Темболее, что ансэйф != анменеджед, т.е. 80% кода все же будет безопастным, а опасные куски будут все в коде как на ладони и их проконтролировать будет не сложно.


Я плохо представляю себе, как может быть безопасным unsafe-код. Произвольная реинтерпретация памяти, она и в Африке грабля. И в чем отличие unsafe от unmanaged? Только лишь в отличие байт-кода от нативного? Это непринципиально при прямом доступе к памяти или другим частям железки.


VD>Разработчики Сингулярити как раз постоянно акцентируют внимание на том, что у них все совсем не как во встраеваемых Явах. Они указывают только на какую-то одну реализацию (какю не помню) и то говорят, что там мол не все честно.


С т.з. прикладных программ абсолютно нет никакой разницы, какой процент нативного кода содержится в ядрах таких ОС. Что касается текущего положения вещей, то эти Ява-ОС ориентированы на всякие мелкие устройства, типа телефонов или карманных ПК, у которых откровенно слабые вычислительные возможности. Поэтому вопрос наличия приличной доли нативного кода в таких ОС — это вопрос вообще физической реализуемости данного подхода с приемлимыми потребительскими качествами.

Разумеется, разработчикам ПРОЩЕ было бы вообще все писать на Java, но речь не о разработчиках, а о потребителях. В противовес Java-OS, Сингулярити нацелилось на десктопный рынок, потому и может себе позволить гораздо большее, ввиду просто фантастических вычислительных мощностей современных десктопов.


VD>ОС может оказаться медленной относительно традиционных. Они слишком подчеркивают, что не производительность для них не главное.


Потенциально — не медленнее. Все же, работа в едином адресном пространстве, да еще без переключения режимов исполнения несет массу бенефитов именно в плане быстродействия. Просто, они наверняка не вылизывают алгоритмы, ибо действительно, сейчас это не главное. Я тоже самое тебе говорил в топике Муравья в "проектах".

VD>По крайней мере хочется в это верить, так как сегоднящние NT и Линкус — это дырявые колоши с доисторической архитекрутрой.


Проблема современных ОС в том, что к ним предъявляется жестокое требование универсальности. И этот опыт был накоплен только буквально в 90-х годах. ПО дожило до того, что вынужденно защищаться от другого ПО, и складвается впечатление, что на сегодняшний день нет более важной задачи. Похоже, мы дожили до кульминации — ПО будет полностью анализироваться перед исполнением. Занавес.
Re[26]: С++ culture
От: vdimas Россия  
Дата: 08.01.06 06:31
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А ты вот это читал ftp://ftp.research.microsoft.com/pub/tr/TR-2005-135.pdf ?

VD>

Code in Singularity is either verified or trusted. Verified code’s type and memory safety is
VD>checked by a compiler. Unverifiable code must be trusted by the system and is limited to the
VD>hardware abstraction layer (HAL), kernel, and parts of the run-time system. Most of the kernel is
VD>verifiably safe
, but portions are written in assembler, C++, and unsafe C#.
VD>All other code is written in a safe language, translated to safe Microsoft Intermediate
VD>Language (MSIL)4, and then compiled to x86 by the Bartok compiler [20]. Currently, we trust
VD>that Bartok correctly verifies and generates safe code. This is obviously unsatisfactory in the long
VD>run
and we plan to use typed assembly language to verify the output of the compiler and reduce
VD>this part of the trusted computing base to a small verifier [36]


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


VD>Кстати, при всем при том, что они говорят о защите на уровне безоспасного кода... все же они же говорят и о страничной подкачке. Это уже и в мою буйную на фантазию голову войти не может.


А в чем противоречие? У них x86 работает в защищенном режиме, имеет виртуальную память (или ты считал, что они ограничаться лишь объемом физической?). Просто вся эта бодяга работает в едином уровне исполнения и не переключает контексты (как при переключении процессов в других ОС). Все остальное остается в силе. Потому я и считаю, что подобную ОС можно разрабатывать и отлаживать прямо в виндах как обычный процесс, подсунув эмуляторную реализацию HAL.


V>>Я говорил имено про unmanaged код в том первом абзаце. В принципе, если ты напираешь на "дыру" в С++ в виде возможности произвольной реинтерпретации памяти в С++, то твой unsafe позволяет точно такое же.


VD>Такой же, да не такой же. В нем все опасные точки специфицируются и могут быть проконтролированны.


Я наверно чего-то упустил. Но так и не понял разницы. Вернее не представляю, как эти опасные куски кода могут быть проконтроллированы лучше, например, чем в С++? И если уж сравнивать инструменты, то для генерации небезопасного кода мне С++ представляется на голову выше по удобством. Я обкладываю программы на С++ жесткой статической типизацией, и при этом не трачу на это много усилий ввиду мощи шаблонов. А unsafe в C# по возможностям недалеко ушел от обычного С, т.е. каменный век. В общем откровенно неудобно и лишает меня чувства безопасности, которое присутствует при "правильной" разработке на С++.

Сдается мне, что советы писать unsafe-куски на C# — это из области религии. Особенно в свете вышедшего С++/CLI.
Re[13]: С++ culture
От: vdimas Россия  
Дата: 08.01.06 06:32
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Kluev, Вы писали:


K>>Дотнетовский массив — это ссылочный тип который в GC-хипе аллоцируется. В NET нельзя сделать массив частью аггрегата, как в С++:


AVK>
AVK>struct CSharpTriangle
AVK>{
AVK>  public fixed Node nodes[3];
AVK>}
AVK>


К превеликому сожалению данная конструкция является unsafe. А доступ к массиву возможен только внутри fixed-выражения.
Re[27]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.01.06 21:19
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Тебе описали реальную ситуацию, при которой виртуальные 2 гига набиты под завязку. Я охотно соглашусь лишь с тем, что у тебя лично ситуация обстоит по другому.


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

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

V>Вот не могу добиться уточнения твоей т.з. на этот момент. Еще раз. Unsafe код в Сингулярити допустим только внутри "пояса безопасности". В этот пояс безопасности входит только сама VM и микроядро. Драйвера НЕ МОГУТ содержать небезопасный код. И мне уже прямо сейчас нетерпиться узнать, пойдут они на компроммиссы или нет к моменту выпуска коммерчесского варианта. Невзирая на мощность техники к тому моменту. А тож блин опять введут нечто вроде: "подписанный unsafe-драйвер", и будет всем смешно.


Драйверы не могут содержать небезопасный код. Но это не значит, что процесс драйверов не может содержать доверительного небезопасного кода. В описании Синкулярити сказано, что в код драйверов подмешивается доверительный код (на базе CTR — рефлексии времени компиляции). Точно так же код прикладных процессов может содержать доверительный код генерируемый компилятором или рантайомом. Так что безопасность драйверов не означает невозможность использования трюков повышающих производительность.

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

Меня вообще занимает не технический, а марально-экономический аспект. Ведь у МС есть 100 тысяч драйверов написаных на С/С++ которые для новой ОС прийдется переписать с нуля. Пусть даже на 2 трети они забьют, но ведь и без этого объем работы колосальный! А ведь еще прийдется переписать GUI, 3D, средства комуникции, серверы приложений... Один MS SQL — это уже огромнейшая работа.

Думаю это куда как посерьезнее каких-то технический проблем.

VD>>Вроде как ЖЦ использует ансэйф-код.


V>Разумеется. Он же памятью оперирует.


А что есть пмять? Набор байтов... Так что можно представить ее как массив байтов.

V>Я плохо представляю себе, как может быть безопасным unsafe-код.


В unsafe можно помечать ключевым словом unsafe только конкретные блоки кода. При этом даже внутри них все манипуляции с управляемыми типами будут безопасны. Так что общая надежность будет выше. unsafe же можно попытаться контролировать другими средствами. Например, допускать unsafe только если он генерируется по некоторым шаблонам (проверенным и безопасным).

V> Произвольная реинтерпретация памяти, она и в Африке грабля.


Дык сколько ее там надо?

V> И в чем отличие unsafe от unmanaged? Только лишь в отличие байт-кода от нативного? Это непринципиально при прямом доступе к памяти или другим частям железки.


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

V>Разумеется, разработчикам ПРОЩЕ было бы вообще все писать на Java, но речь не о разработчиках, а о потребителях. В противовес Java-OS, Сингулярити нацелилось на десктопный рынок, потому и может себе позволить гораздо большее, ввиду просто фантастических вычислительных мощностей современных десктопов.


Думаю Сингулярити ни на что не рассчитана. Это исследование. И что оно покажет еще чер не знает. Вот они уже хвастаются очень малым расходом памяти на процессы.

V>Потенциально — не медленнее. Все же, работа в едином адресном пространстве, да еще без переключения режимов исполнения несет массу бенефитов именно в плане быстродействия. Просто, они наверняка не вылизывают алгоритмы, ибо действительно, сейчас это не главное. Я тоже самое тебе говорил в топике Муравья в "проектах".


Согласен. Но есть еще плата за софтовую безопасность. Хотя чем дальше в лес, тем меньше это убдет влиять на производительность, так как оптимизации все время становятся все мощьнее и мощьнее.

V>Проблема современных ОС в том, что к ним предъявляется жестокое требование универсальности. И этот опыт был накоплен только буквально в 90-х годах. ПО дожило до того, что вынужденно защищаться от другого ПО, и складвается впечатление, что на сегодняшний день нет более важной задачи. Похоже, мы дожили до кульминации — ПО будет полностью анализироваться перед исполнением. Занавес.


Давно пора.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.01.06 23:55
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Ну, вообще-то, ничто не мешает держать управляющие структуры (для GC)

Pzz>отдельно от блоков собственно памяти, доступных приложению. В таком
Pzz>случае, GC вовсе не обязано вызывать интенсивный свопинг.

"Управляющие структуры" хранятся внутри каждого объекта.

Дело в том, что даже банальный алогоритм определения достижимого графа объектов требует помечать найденные объекты. Да и сам перебор ведется непосредственно по самим объектам. Нельзя же хнанить отдельно поля объекта?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.01.06 02:08
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Чтобы помечать объекты, нужен флаг. Что мешает хранить эти флаги в

Pzz>отдельной кучке?

А как ты сопоставишь эти отдельные флаги с объектами? И ты представляшь себе их количество? Их же должно быть столько сколько объектов.

К тому же граф строится путем объхода самих объектов. Их полей.

В общем, лечше разберись в вопросе, а то твои предложения звучат совсем смешно.
... << RSDN@Home 1.2.0 alpha rev. 627>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: С++ culture
От: Cyberax Марс  
Дата: 09.01.06 08:22
Оценка:
VladD2 wrote:
> Pzz>Ну, вообще-то, ничто не мешает держать управляющие структуры (для GC)
> Pzz>отдельно от блоков собственно памяти, доступных приложению. В таком
> Pzz>случае, GC вовсе не обязано вызывать интенсивный свопинг.
> "Управляющие структуры" хранятся внутри каждого объекта.
Pzz совершенно прав — нормальный GC не должен свопить во время малых
сборок, так как все нужные страницы и так уже есть в памяти. Вот во
время большой сборки — действительно нужно все загружать.

> Дело в том, что даже банальный алогоритм определения достижимого графа

> объектов требует помечать найденные объекты. Да и сам перебор ведется
> непосредственно по самим объектам. Нельзя же хнанить отдельно поля объекта?
Все просто — не надо обходить ВСЕ объекты, а только те, которые
изменились с предидущей сборки. Это достигается с помощью card marking'а
или трюков с защитой памяти.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[32]: С++ culture
От: Pzz Россия https://github.com/alexpevzner
Дата: 09.01.06 11:03
Оценка:
VladD2 wrote:
>
> Pzz>Чтобы помечать объекты, нужен флаг. Что мешает хранить эти флаги в
> Pzz>отдельной кучке?
>
> А как ты сопоставишь эти отдельные флаги с объектами? И ты представляшь
> себе их количество? Их же должно быть столько сколько объектов.
>
> К тому же граф строится путем объхода самих объектов. Их полей.
>
> В общем, лечше разберись в вопросе, а то твои предложения звучат совсем
> смешно.

Это от недостатка воображения

Я думаю, что реально спроектировать систему управления памятью, которая
не будет поднимать все объекты из свопа с целью сборки мусора. Но я не
буду заниматься доказательством этого утверждения...
Posted via RSDN NNTP Server 2.0
Re[28]: С++ culture
От: vdimas Россия  
Дата: 09.01.06 11:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>ЖЦ и виртуальная память плохо дружат. Дело в том, что сборка мусора поднимит все данные в память, и если физической памяти не хватает, то начнется кольцивой свопинг, так что для ОС основанной на ЖЦ вопрос с виртуальной памяти можно не рассматривать.


Вопрос в том, когда начинается сеанс GC. Даже в такой ОС GC должен работать в пределах приложения. Далее. У разработчиков ОС есть все возможности по контролю страниц виртуальной памяти. Т.е. работу GC можно связать с менеджером виртуальной памяти. Например, перед отправлением страницы на диск, выполнять GC в этом процессе, запоминать/отмечать сей факт и т.д. Т.е. можно продумать, как избежать подъема виртуальных страниц в процессе GC.

Я уверен, что GC исполняется не медленнее, чем запись страниц виртуальной памяти на диск. К тому же, нам опять же не надо переключать контексты в нашем едином адресном пространстве. Поэтому, подобные способы вряд ли сильно замедлят общую картинку. Опять же, после сеанса GC. Опять же, после сеанса GC нам в общем случае придется скидывать на диск меньше страниц, что еще более улучшит время свопа.

VD>Когда же подобная ОС дойдет до промышленной эксплуатации, то говорить о чем-то отличном от 64-битных камней будет не серьезно. Ну, или на них можно смело бабить.


Может быть. Хотя, я уверен, что в первую очередь эта ОС получит распространение на всяких встраиваемых устройствах, или там WEB-терминалах, или банкоматах и т.д. И надо признать, что в этих задач требования к памяти далеко не астрономические.


VD>Драйверы не могут содержать небезопасный код. Но это не значит, что процесс драйверов не может содержать доверительного небезопасного кода. В описании Синкулярити сказано, что в код драйверов подмешивается доверительный код (на базе CTR — рефлексии времени компиляции). Точно так же код прикладных процессов может содержать доверительный код генерируемый компилятором или рантайомом. Так что безопасность драйверов не означает невозможность использования трюков повышающих производительность.


Вопрос стоит более прямо. Смогу я залезть из драйвера в произвольную область памяти или нет? Ответ для меня важен, сам понимаешь почему.

VD>Меня вообще занимает не технический, а марально-экономический аспект. Ведь у МС есть 100 тысяч драйверов написаных на С/С++ которые для новой ОС прийдется переписать с нуля. Пусть даже на 2 трети они забьют, но ведь и без этого объем работы колосальный! А ведь еще прийдется переписать GUI, 3D, средства комуникции, серверы приложений... Один MS SQL — это уже огромнейшая работа.


V>> И в чем отличие unsafe от unmanaged? Только лишь в отличие байт-кода от нативного? Это непринципиально при прямом доступе к памяти или другим частям железки.


VD>Отличие в том, что при манипуляции с управляемымии данными ты защищен от ошиблок.


Угу, пока не сделали fixed. И прощай все.


VD>Думаю Сингулярити ни на что не рассчитана. Это исследование. И что оно покажет еще чер не знает. Вот они уже хвастаются очень малым расходом памяти на процессы.


Я предполагал нечто подробное. Более того, потом можно будет хвастаться миниатюрным размером самих приложений.
Re[33]: С++ culture
От: vdimas Россия  
Дата: 09.01.06 11:46
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Я думаю, что реально спроектировать систему управления памятью, которая

Pzz>не будет поднимать все объекты из свопа с целью сборки мусора. Но я не
Pzz>буду заниматься доказательством этого утверждения...

Даже этого ничего не надо. Сам GC и подсистема управления виртуальной памятью могут быть объединены в единый механизм. Т.е. у GC должна быть вся информация о наличии или отсутствии страниц в памяти.
Re[31]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.01.06 12:12
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Pzz совершенно прав — нормальный GC не должен свопить во время малых

C>сборок, так как все нужные страницы и так уже есть в памяти. Вот во
C>время большой сборки — действительно нужно все загружать.

ЖЦ можно разделить на два вида. 1. Основанных на поколениях. 2. Все остальные (в том числе реалтаймнве инкриментальные).

Так вот первые будут приводить к свопингу при сборке второго поколения. Вторые — всегда. Учитывая же, что при реализации ЖЦ все авторы стремятся собрать память во втором поколениии если не хватает свободной физической памяти, то автоматически будет начинаться вопинг.

Короче вы живете в каком-то страном мире сових фантазий. Между тем ЖЦ-алгоритмы принципиально не рассчитаны на жизнь в условиях когда физической памяти меньше чем виртуальной занятой. И тут ничего не поделаешь. Попробуйте создать эксперемент с Явой или дотнетом. Создайте много объектов в начале работы приложения и поместите их в массив. Их объем должен быть на уровне объема физической памяти доступной в системе. Далее начните в цикле создавать и удалять объекты. Увидите, что ваше приложение сурово сядет на своп. А елси при этом посмотреть на поведение ЖЦ, то можно будет заметить Н-ное количество сборок мусора второго покления. Ворксет процесса при этом будет постоянно подниматься и опускаться.

C>Все просто — не надо обходить ВСЕ объекты, а только те, которые

C>изменились с предидущей сборки. Это достигается с помощью card marking'а
C>или трюков с защитой памяти.

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

В общем, ЖЦ и виртуалка хреново совмещаются. Так что не велика потеря. Ну, или прийдется изобретать новые приципы работы с вируалкой. Я лично пока что их не вижу.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: С++ culture
От: Pzz Россия https://github.com/alexpevzner
Дата: 09.01.06 12:35
Оценка:
vdimas wrote:
>
> Pzz>Я думаю, что реально спроектировать систему управления памятью, которая
> Pzz>не будет поднимать все объекты из свопа с целью сборки мусора. Но я не
> Pzz>буду заниматься доказательством этого утверждения...
>
> Даже этого ничего не надо. Сам GC и подсистема управления виртуальной
> памятью могут быть объединены в единый механизм. Т.е. у GC должна быть
> вся информация о наличии или отсутствии страниц в памяти.

В нормальной ОС на обычном железе это трудно сделать, т.к. paging в
ядре, а GC в user space. Кроме того, GC очень уж language и
application-specific, а paging это гораздо более общая вещь.

Впрочем, "трудно" не означает "невозможно".
Posted via RSDN NNTP Server 2.0
Re[34]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.01.06 12:37
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Даже этого ничего не надо. Сам GC и подсистема управления виртуальной памятью могут быть объединены в единый механизм. Т.е. у GC должна быть вся информация о наличии или отсутствии страниц в памяти.


Предположим, что это есть (такие реализации даже есть в природе). И как при этом ты видишь рабту ЖЦ?

Ну, предположим ЖЦ знает что куча памяти из не эфимерного поколения находится в свопе, но он так же знает, что другая куча все еще в памяти и возможно в ней куча мусра. Возникает дилема. Или скинуть оставшуюся часть памяти в своп. Или произвести сборку мусора. И что выбрать?

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

Первая же полная сборка и весь своп будет в памяти.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.01.06 12:37
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Вопрос в том, когда начинается сеанс GC. Даже в такой ОС GC должен работать в пределах приложения.


И что?

V> Далее. У разработчиков ОС есть все возможности по контролю страниц виртуальной памяти. Т.е. работу GC можно связать с менеджером виртуальной памяти.


Это можно сделать и сейчас. Особенно МС.

V> Например, перед отправлением страницы на диск, выполнять GC в этом процессе, запоминать/отмечать сей факт и т.д. Т.е. можно продумать, как избежать подъема виртуальных страниц в процессе GC.


Ты вообще понимашь что говоришь? Представь себе. ОС хочет скинуть 10 страниц на винт и ради этого она будет проводить ЖЦ вего процесса.

К тому же ЖЦ такой механизм, что тонна мусора может появиться в результате правки одного указателя. Так что правка одной страницы может привести к тому, что большая часть отсвапованных страниц будет мусором. Но чтобы это выяснить прйдется загрузить все в память и произвести сборку мусора.

V>Я уверен, что GC исполняется не медленнее, чем запись страниц виртуальной памяти на диск.


Это зависит. Например полный ЖЦ может длиться секунды (особенно инкриментальный) на большом процессе. Но не об этом речь. Ты мехонизм опиши. Как ВМ и ЖЦ будут жить и не драться между собой? В Виндовс они дерутся по страшному.

V> К тому же, нам опять же не надо переключать контексты в нашем едином адресном пространстве.


И? Одна операция с винтом стоит тысячи переключений контекста.

V> Поэтому, подобные способы вряд ли сильно замедлят общую картинку. Опять же, после сеанса GC. Опять же, после сеанса GC нам в общем случае придется скидывать на диск меньше страниц, что еще более улучшит время свопа.


А есть ли смысл вообще что-то куда-то скидывать? Ведь копирующий ЖЦ обеспечивает дефрагментацию памяти. Так что в ней будет только то что нужно.

Может лучше вместо виртуальной памяти задействовать механизмы вроде кибирнейма процессов? Преставь себе. ОС заметила, что процесс простаивает на протяжении нескольких минут. Она прото берет и сериализует состояние процесса на диск. Когда к процессу идет обращение она зачитывает процесс в нужную область памяти. Ну, а на виртуалку прйдется перемещение страниц.

V>Может быть. Хотя, я уверен, что в первую очередь эта ОС получит распространение на всяких встраиваемых устройствах, или там WEB-терминалах, или банкоматах и т.д. И надо признать, что в этих задач требования к памяти далеко не астрономические.


Думаю, что удачная ОС нашла бы себе применение везде. Вот только надо чтобы ее проталкивали монстры вроде МС. А то даже самая удачная идея загнется.

V>Вопрос стоит более прямо. Смогу я залезть из драйвера в произвольную область памяти или нет? Ответ для меня важен, сам понимаешь почему.


Ты, как программист — нет. Но ОС может помочь тебе оптимизировав те или иные операции.
Вот для обмена сообщениями Сингулярити явно занимается хаками. Там физически передаются только адреса, а сами сообщения лежат в разделяемой куче.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: С++ culture
От: Cyberax Марс  
Дата: 09.01.06 13:52
Оценка:
VladD2 wrote:
> ЖЦ можно разделить на два вида. 1. Основанных на поколениях. 2. Все
> остальные (в том числе реалтаймнве инкриментальные).
FYI, инкрементальные GC вполне себе работают с поколениями. Насчет
realtime особо не интересовался.

> Так вот первые будут приводить к свопингу при сборке второго поколения.

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

> Это можно сделать только при эфимерной сборке.

Кстати, пишется "эфемерной". А то уже несколько человек начали
неправильно писать это слово вслед за тобой

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[33]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.01.06 15:58
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> ЖЦ можно разделить на два вида. 1. Основанных на поколениях. 2. Все

>> остальные (в том числе реалтаймнве инкриментальные).
C>FYI, инкрементальные GC вполне себе работают с поколениями.

Икриментальные ЖЦ не могут рабоать с поколениями. Это разные алгоритмы. Можно их испльзовать совместно. Например, использовать инкрементальный ЖЦ для полной сборки и обычный, копирующий для эфимерных поколений. Но это уже будет гибрид наследующий все свойства обоих методов. А у обоих кроме хороший сторон есть еще и плохие.

В любом случае при поной сборке мусора подъма всех объектов в память не избежать.

C>Насчет realtime особо не интересовался.


Еще не все потеряно.

>> Так вот первые будут приводить к свопингу при сборке второго поколения.

C>Я вроде бы говорил про сборку вообще. Понятно, что при полном цикле
C>сборки придется загрузить все объекты.

Дык, а когда и зачем по-твоему производится полная сборка мусора? Один из случаев — нехватка памяти. Так что на лицо пардокс. При нехватке памяти нужно запускать полную сборку, а она еще больше усугубит положение.

C>Хотя и тут возможны варианты

C>(кластеры объектов, например).

Какие кластеры? Ты можешь двигать объекты совмесно, но вычисление графа при полной сборке неминуемо поднимит все объекты в память.

>> Это можно сделать только при эфимерной сборке.

C>Кстати, пишется "эфемерной". А то уже несколько человек начали
C>неправильно писать это слово вслед за тобой

Да, я все время путаю его написание. Ну, да это не единственное изковерканное мной слово .

C>--

C>С уважением,
C> Alex Besogonov (alexy@izh.com)

Убири, пожалуйста, свою подпись в профайл. Это сэкономит место на сервере и избавит других от необходимости каждый раз удалять ее.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: С++ culture
От: Cyberax Марс  
Дата: 09.01.06 16:15
Оценка:
VladD2 wrote:
>> > ЖЦ можно разделить на два вида. 1. Основанных на поколениях. 2. Все
>> > остальные (в том числе реалтаймнве инкриментальные).
> C>FYI, инкрементальные GC вполне себе работают с поколениями.
> Икриментальные ЖЦ не могут рабоать с поколениями. Это разные алгоритмы.
> Можно их испльзовать совместно. Например, использовать инкрементальный
> ЖЦ для полной сборки и обычный, копирующий для эфимерных поколений. Но
> это уже будет гибрид наследующий все свойства обоих методов. А у обоих
> кроме хороший сторон есть еще и плохие.
Я это знаю. Просто ваше деление на два типа: generational и incremental
неверное.

> Дык, а когда и зачем по-твоему производится полная сборка мусора? Один

> из случаев — нехватка памяти. Так что на лицо пардокс. При нехватке
> памяти нужно запускать полную сборку, а она еще больше усугубит положение.
Значит надо думать как это исправить.

> C>Хотя и тут возможны варианты

> C>(кластеры объектов, например).
> Какие кластеры? Ты можешь двигать объекты совмесно, но вычисление графа
> при полной сборке неминуемо поднимит все объекты в память.
Очень часто объекты хранятся в виде массивов (в коллекциях, например), и
одной из консервативных стратегий оптимизации является политика "если
есть ссылка на объект коллекции, то значит вся коллекция живая". Это
позволяет не проверять все объекты массива — получается неплохой прирост
в производительности. Есть еще несколько хитрых алгоритмов — на ACMе
было, но у меня сейчас нет туда доступа.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[35]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.01.06 17:36
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Я это знаю. Просто ваше деление на два типа: generational и incremental

C>неверное.

Не на generational и incremental, а на generational и остальные. Гибриды все равно являются generational.

>> Дык, а когда и зачем по-твоему производится полная сборка мусора? Один

>> из случаев — нехватка памяти. Так что на лицо пардокс. При нехватке
>> памяти нужно запускать полную сборку, а она еще больше усугубит положение.
C>Значит надо думать как это исправить.

Уже многие думали. Ну, да если будет решение, пиши. Может двинишь науку вперед.

C>Очень часто объекты хранятся в виде массивов (в коллекциях, например), и

C> одной из консервативных стратегий оптимизации является политика "если
C>есть ссылка на объект коллекции, то значит вся коллекция живая". Это
C>позволяет не проверять все объекты массива — получается неплохой прирост
C>в производительности. Есть еще несколько хитрых алгоритмов — на ACMе
C>было, но у меня сейчас нет туда доступа.

Масси может хранить ссылочные или влэью-типы. Причем вэлью-типы могут содержать или не содержать ссылочные поля. Только в случае если массив хранит вэлью-типы не содержащие ссылочные поля можно можно не сканировать все тело массива. Более того так оно и происходит на практике. В других же случаях прийдется проводить сканирование, так как нельзя предсказать на что ссылаются ячейки массива (или поля внедренных в него вэлью-типов).

Надеюсь не нужно обяснить что означает сканирование?
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: С++ culture
От: Cyberax Марс  
Дата: 10.01.06 05:33
Оценка:
VladD2 wrote:
> C>Я это знаю. Просто ваше деление на два типа: generational и incremental
> C>неверное.
> Не на generational и incremental, а на generational и остальные. Гибриды
> все равно являются generational.
Тогда извиняюсь, неправильно понял.

> C>Значит надо думать как это исправить.

> Уже многие думали. Ну, да если будет решение, пиши. Может двинишь науку
> вперед.
Год назад об этом думал очень плотно — была пара новых идей как слегка
ускорить GC. Сейчас мне больше интересны алгоритмы детерминированого
управления памятью и их взаимодействие с GC.

Кстати, нашел интересную статью:
http://citeseer.ist.psu.edu/levanoni01fly.html — как с помощью простого
refcounter'а увеличить отзывчивость GC на два порядка.

> Масси может хранить ссылочные или влэью-типы.Причем вэлью-типы могут

> содержать или не содержать ссылочные поля.
Смысл как раз в том, что это все упаковывается во время первой полной
сборки в "кластер", который идет сплошным блоком в памяти (и не
ссылается на другие объекты). Достаточно часто это бывает возможно, что
дает некоторый прирост в скорости.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[37]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.01.06 11:35
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Кстати, нашел интересную статью:

C>http://citeseer.ist.psu.edu/levanoni01fly.html — как с помощью простого
C>refcounter'а увеличить отзывчивость GC на два порядка.

У меня на эту ссылку открывается какя-то фигня. Но судя по слову "refcounter" речь идет о подсчете ссылок.
У этого подхода куча своих проблем. И даже спаривание его с рассчетом графа достижимости не дает хорошего резельтата.

C>Смысл как раз в том, что это все упаковывается во время первой полной

C>сборки в "кластер", который идет сплошным блоком в памяти (и не
C>ссылается на другие объекты). Достаточно часто это бывает возможно, что
C>дает некоторый прирост в скорости.

Что там возможно? Пойми, нельзя изменять формат объекта на ходу. А ссылка в лбой момент может измениться и начать указывать бог знает куда. Так что при полной сборке мусора никуда от полного сканирования графа объектов не уйти. Это инвариант алгоритма. От этого никуда не уйти.

C>--

C>С уважением,
C> Alex Besogonov (alexy@izh.com)

Еща раз прошу пернести подпись в профайл.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: С++ culture
От: Cyberax Марс  
Дата: 10.01.06 12:47
Оценка:
VladD2 wrote:
> C>Кстати, нашел интересную статью:
> C>http://citeseer.ist.psu.edu/levanoni01fly.html — как с помощью простого
> C>refcounter'а увеличить отзывчивость GC на два порядка.
> У меня на эту ссылку открывается какя-то фигня. Но судя по слову
> "refcounter" речь идет о подсчете ссылок.
Там в правом верхнем углу ссылка на PDF.

Вот прямая ссылка, но на PS:
http://www.cs.technion.ac.il/%7Eerez/Papers/refcount.ps
Взято отсюда: http://www.cs.technion.ac.il/~erez/publications.html

> У этого подхода куча своих проблем. И даже спаривание его с рассчетом

> графа достижимости не дает хорошего резельтата.
Как раз наоборот — за счет refcount'а сразу убивается куча объектов
нулевого поколения.

> C>Смысл как раз в том, что это все упаковывается во время первой полной

> C>сборки в "кластер", который идет сплошным блоком в памяти (и не
> C>ссылается на другие объекты). Достаточно часто это бывает возможно, что
> C>дает некоторый прирост в скорости.
> Что там возможно? Пойми, нельзя изменять формат объекта на ходу. А
> ссылка в лбой момент может измениться и начать указывать бог знает куда.
Ты не понял, во время цикла полной сборки граф объектов разделяется на
набор кластеров. При этом кластеры характеризуются тем, что не имеют
ссылок на внешние относительно кластера объекты. Затем эти кластеры
упаковываются в памяти таким образом, что их объекты расположены всплошную.

Соответственно, достаточно часто можно делать предположение, что если
есть ссылка на любой объект кластера, то весь кластер можно оставить
жить. При этом кластер не имеет ссылок на внешние объекты, так что его
не надо сканировать.

> Так что при полной сборке мусора никуда от полного сканирования графа

> объектов не уйти. Это инвариант алгоритма. От этого никуда не уйти.
Полный обход можно оптимизировать, если принять некоторые консервативные
предположения.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[39]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.01.06 20:56
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Там в правом верхнем углу ссылка на PDF.


Ага. Понял. Я часто попадал на такие же страницы, но никак не мог понять, что с ними делать.

Ладно. Спасибо, погляжу. Хотя уже заголовок уже все говорит за себя.

>> У этого подхода куча своих проблем. И даже спаривание его с рассчетом

>> графа достижимости не дает хорошего резельтата.
C>Как раз наоборот — за счет refcount'а сразу убивается куча объектов
C>нулевого поколения.

Проблема в том, что подсчет ссылок, особенно в многозадачной среде — это довольно дорогое удовольствие. Есть не одна научная работа доказывающая, что инкрементальный коллектор дает лучшие результаты.

Основаня проблема в том, что каждый инкремент/декремент должен сопровождаться блокировкой. А это довольно дорогое удовольствие. Блокировка может в 4-5 раз сократить эффективность. А ведь инкремент/декремент происходит при кадом копировании ссылок.

Вторая проблема — циклы. Для их разруливания один фиг приходится строить граф достицимости. А тогда инкрементальная схема уже мало чем отличается.

C>Ты не понял, во время цикла полной сборки граф объектов разделяется на

C>набор кластеров. При этом кластеры характеризуются тем, что не имеют
C>ссылок на внешние относительно кластера объекты. Затем эти кластеры
C>упаковываются в памяти таким образом, что их объекты расположены всплошную.

А как это ты обеспечишь, что в этих кластерах не будет перекресных ссылок? Это на каждое пересечение кластеров нужно строить набор корней класстеров. А это ой как не дешево.

C>Соответственно, достаточно часто можно делать предположение, что если

C>есть ссылка на любой объект кластера, то весь кластер можно оставить
C>жить.

Ерунда. Ссылка может быть на один листовой объект. Тут без анализа ничерта не сделашь.

C> При этом кластер не имеет ссылок на внешние объекты, так что его

C>не надо сканировать.

Так тоже быть не может. Ссылки будут обязательно. Без хранения корней класстера это работать не будет.

>> Так что при полной сборке мусора никуда от полного сканирования графа

>> объектов не уйти. Это инвариант алгоритма. От этого никуда не уйти.
C>Полный обход можно оптимизировать, если принять некоторые консервативные
C>предположения.

Какие?
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: С++ culture
От: Дарней Россия  
Дата: 11.01.06 06:42
Оценка:
Здравствуйте, Ligen, Вы писали:

L>(хотя фраза "зачем мне это знать?" звучит всегда дико и убийственно, ИМХО).


Во многом знании много печали, и преумножающий знания преумножает скорбь. (С) Экклезиаст
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[40]: С++ culture
От: Cyberax Марс  
Дата: 11.01.06 09:06
Оценка:
VladD2 wrote:
> C>Там в правом верхнем углу ссылка на PDF.
>
> Ага. Понял. Я часто попадал на такие же страницы, но никак не мог
> понять, что с ними делать.
>
> Ладно. Спасибо, погляжу. Хотя уже заголовок уже все говорит за себя.
>
>> > У этого подхода куча своих проблем. И даже спаривание его с рассчетом
>> > графа достижимости не дает хорошего резельтата.
> C>Как раз наоборот — за счет refcount'а сразу убивается куча объектов
> C>нулевого поколения.
>
> Проблема в том, что подсчет ссылок, особенно в многозадачной среде — это
> довольно дорогое удовольствие. Есть не одна научная работа доказывающая,
> что инкрементальный коллектор дает лучшие результаты.
>

> Основаня проблема в том, что каждый инкремент/декремент должен

> сопровождаться блокировкой. А это довольно дорогое удовольствие.
Которого вполне можно избежать в большинстве случаев Предположим, что
при первом использовании переменной в текущем потоке мы увеличиваем ее
счетчик на 1 и создаем thread-local счетчик. Теперь мы можем его
нормально инкрементировать и декрементировать — блокировка нужна будет
только когда локальный счетчик дойдет до 0.

> Вторая проблема — циклы. Для их разруливания один фиг приходится строить

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

> А как это ты обеспечишь, что в этих кластерах не будет перекресных

> ссылок? Это на каждое пересечение кластеров нужно строить набор корней
> класстеров. А это ой как не дешево.
В кластеры загоняются не все объекты, это я немного неясно выразился. То
есть часть объектов так и остается в виде обычном некластеризованом виде.

> C>Соответственно, достаточно часто можно делать предположение, что если

> C>есть ссылка на любой объект кластера, то весь кластер можно оставить
> C>жить.
> Ерунда. Ссылка может быть на один листовой объект. Тут без анализа
> ничерта не сделашь.
Я же говорю — консервативное предположение, которое обычно вполне
оправдывается. Можно использовать эвристику — после создания кластера во
время первой полной сборки проверить будет ли кластер жив целиком.

> C> При этом кластер не имеет ссылок на внешние объекты, так что его

> C>не надо сканировать.
> Так тоже быть не может. Ссылки будут обязательно. Без хранения корней
> класстера это работать не будет.
Корни ссылаются _на_ кластер, из самого кластера ссылок вовне нет.

> C>Полный обход можно оптимизировать, если принять некоторые консервативные

> C>предположения.
> Какие?
Кластерная стратегия, partial-scan и т.п.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[41]: С++ culture
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.01.06 11:31
Оценка:
Здравствуйте, Cyberax, Вы писали:
>> Основаня проблема в том, что каждый инкремент/декремент должен
>> сопровождаться блокировкой. А это довольно дорогое удовольствие.
C>Которого вполне можно избежать в большинстве случаев Предположим, что
C>при первом использовании переменной в текущем потоке мы увеличиваем ее
C>счетчик на 1 и создаем thread-local счетчик. Теперь мы можем его
C>нормально инкрементировать и декрементировать — блокировка нужна будет
C>только когда локальный счетчик дойдет до 0.
Что-то мне непонятно.
1. Как выполняется передача указателя в другой поток?
2. Я правильно понимаю, что при достижении локального нуля мы блокируемся и начинаем сканировать весь список рефкаунтов на предмет ненулевых значений?
В общем, поясни плиз подробнее.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: С++ culture
От: Kubera Россия  
Дата: 11.01.06 14:59
Оценка:
Здравствуйте, DarkGray, Вы писали:

VD>>А свои что бесплатные? Или все кто пишут на С++ сразу автоматом получают манию величия в форме веры в свою непогрешимость?


DG>Свое бревно — глаз не колет.


Серьёзная потеря адекватности всегда ведёт к плачевным результатам, если не сразу, так в последствии. Так что колит. И весьма ощутимо.
Любая сложная технология неотличима от волшебства. (Артур Кларк)
Re[41]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.01.06 18:57
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Которого вполне можно избежать в большинстве случаев Предположим, что

C>при первом использовании переменной в текущем потоке мы увеличиваем ее
C>счетчик на 1 и создаем thread-local счетчик. Теперь мы можем его
C>нормально инкрементировать и декрементировать — блокировка нужна будет
C>только когда локальный счетчик дойдет до 0.

Это ты совсем что-то несерьезное говоришь. В приведенной тобой статье описывается куда боле хитрый подход — испльзование снимков стостояний и барьера-записи. А делать какие-то локальные счетчки — это не серьезно. Основная проблема — это ссылки делаемые из одного объекта на другой. Такие ссылки могут делаться в разных потоках.

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

>> Вторая проблема — циклы. Для их разруливания один фиг приходится строить

>> граф достицимости. А тогда инкрементальная схема уже мало чем отличается.
C>Тут будет плюс в том, что в реальных приложениях циклы обычно не
C>составляют большей части объектов. Питон, например, как раз и использует
C>refcounter и детектор циклов.

Ну, не скажи. Представь себе AST c кучей ссылок на типы и из типов на их применение. Весь граф объектов будет самозаблокированным.

C>Я же говорю — консервативное предположение, которое обычно вполне

C>оправдывается. Можно использовать эвристику — после создания кластера во
C>время первой полной сборки проверить будет ли кластер жив целиком.

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

C>Корни ссылаются _на_ кластер, из самого кластера ссылок вовне нет.


Это нереально.

>> C>Полный обход можно оптимизировать, если принять некоторые консервативные

>> C>предположения.
>> Какие?
C>Кластерная стратегия, partial-scan и т.п.

Предположения какие?
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: С++ culture
От: Воронков Василий Россия  
Дата: 12.01.06 19:45
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Будет ли один и тот же человек одинаково производительным, пользуясь разными инструментами?


А ты уверен, что этот человек должен интересоваться этим вопросом?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[35]: С++ culture
От: vdimas Россия  
Дата: 16.01.06 19:56
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>В нормальной ОС на обычном железе это трудно сделать, т.к. paging в

Pzz>ядре, а GC в user space. Кроме того, GC очень уж language и
Pzz>application-specific, а paging это гораздо более общая вещь.

Рассматриваемая ОС — это единый процесс с плоской памятью, все работает в режиме ядра. GC — это единственный механизм управления памятью в этой ОС.

Pzz>Впрочем, "трудно" не означает "невозможно".


Да, там несколько интересных моментов возникают.
Re[35]: С++ culture
От: vdimas Россия  
Дата: 16.01.06 19:57
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Первая же полная сборка и весь своп будет в памяти.


Угу, маленькая поправка. Полная сборка будет выполняться только у "активного" приложения, которое и так большей своей частью уже в памяти.
Re[36]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.01.06 00:12
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Угу, маленькая поправка. Полная сборка будет выполняться только у "активного" приложения, которое и так большей своей частью уже в памяти.


У активного приложения может быть куче редко используемых объектов которые без ЖЦ спокойно лежали бы себе на винте.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: С++ culture
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.01.06 00:12
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Рассматриваемая ОС — это единый процесс с плоской памятью, все работает в режиме ядра. GC — это единственный механизм управления памятью в этой ОС.


Не единый процесс, а единое адрессное пространство. А процессов там как раз по более чем в обычной ОС будет.
... << RSDN@Home 1.2.0 alpha rev. 628>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: why off?
От: neFormal Россия  
Дата: 31.03.08 19:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>

- Вот все говорят о дотнете, а ведь это полная туфта. На нем же даже игрушку написать нельзя.
VD>- Помилуйте, вот игршка. Загрузите, поглядите.


мм.. а что за игрушки?.
под xna ничего здравого я не встретил.. или здесь имеются ввиду какие то небольшие "паззлы/тетрисы", например, для мобильных устройств?.
...coding for chaos...
Re[16]: why off?
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 01.04.08 10:06
Оценка:
Здравствуйте, Plague, Вы писали:

P>Здравствуйте, VladD2, Вы писали:


VD>>

- Вот все говорят о дотнете, а ведь это полная туфта. На нем же даже игрушку написать нельзя.
VD>>- Помилуйте, вот игршка. Загрузите, поглядите.

P>Например?

http://www.codeproject.com/KB/mcpp/quake2.aspx

Загрузите, поглядите

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[18]: why off?
От: CreatorCray  
Дата: 01.04.08 11:47
Оценка:
Здравствуйте, Plague, Вы писали:

P>1. Уважаемый Кармак пишет настолько хороший код, что можно взять Quake2, изначально требующий 16мб памяти и 90Mhz процессор, скомпилировать и он заработает!

Более того, он пишет если не сразу кроссплатформенные то очень легко портируемые (Win<->Lin) игры.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: С++ culture
От: anton_t Россия  
Дата: 07.04.08 02:15
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>sch wrote:


>> Соответственно, больше всего пугает самое новое и необычное: например,

>> чаще всего у C++ программистов нарекания вызывает GC из .NET. /Боже
>> мой, он будет лазить по моим структурам когда ему захочется, и будет
>> освобождать память! Сам!/

C>Это-то фигня. Больше всего раздражает, что GC уничтожает память

C>недетерминировано. А значит RAII и подобные идиомы не проходят.

Касательно RAII: что вы делаете с исключениями в деструкторах?
Re[32]: С++ culture
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 07.04.08 06:48
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Так вот первые будут приводить к свопингу при сборке второго поколения. Вторые — всегда. Учитывая же, что при реализации ЖЦ все авторы стремятся собрать память во втором поколениии если не хватает свободной физической памяти, то автоматически будет начинаться вопинг.


VD>Короче вы живете в каком-то страном мире сових фантазий. Между тем ЖЦ-алгоритмы принципиально не рассчитаны на жизнь в условиях когда физической памяти меньше чем виртуальной занятой. И тут ничего не поделаешь. Попробуйте создать эксперемент с Явой или дотнетом. Создайте много объектов в начале работы приложения и поместите их в массив. Их объем должен быть на уровне объема физической памяти доступной в системе. Далее начните в цикле создавать и удалять объекты. Увидите, что ваше приложение сурово сядет на своп. А елси при этом посмотреть на поведение ЖЦ, то можно будет заметить Н-ное количество сборок мусора второго покления. Ворксет процесса при этом будет постоянно подниматься и опускаться.


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

От рантайма в этом случае требуется:
1. Принципиальное "осознание" на этапе разработки, что приложение будет работать под VM с "резиновой" памятью, а значит — представление о том, что собирать мусор нужно не только тогда, когда уже по голове стукнули явным отказом (и когда может быть уже поздно), а заранее, исходя из предоставленных системой и уточнённых приложением данных (размер RAM, разрешённую долю использования RAM).
Насколько я помню, во многих рантаймах (например, в Sun JVM) это есть, пусть и не всегда с оптимальными дефолтами.
2. Даже при потреблении ниже установленных границ — регулирование темпа GC таким образом, чтобы не было существенного разрастания за пределы объёма реально используемых данных. Показательный пример здесь даёт Lua: сборка запускается тогда, когда сумма размеров объектов превзошла двойной размер результата предыдущей сборки. У Lua это stop-world, но никто не мешает сделать это и в случае более мягких подходов, поддерживая норму типа "потребление системной памяти на уровне 2-3 суммы размеров объектов".

От системы требуется в основном обеспечение "мягкой посадки" в случае, если приложение всё же вышло за пределы доступной ему памяти (или кончилась в системе совсем, или не пускают дальше лимиты). Недостаточно знаю специфику виндовой VM, но юниксовая может дать проблемы в совершенно неожиданный момент (например, срабатывает copy-on-write, а в системе кончилась вся память), и решение, которое я предлагал для таких VM — принадлежащий процессу пул закоммиченных, но не отображённых в его адресное пространство страниц, которые подключаются как только не оказывается другого источника памяти, плюс к тому механизм оповещения об уменьшении этого пула и подключения новых страниц. Если оказывается, что памяти недостаточно — запасной пул может быть использован для того, чтобы в нём держать данные stop-world прохода. На сейчас я такого механизма запасного пула не видел нигде.

VD>В общем, ЖЦ и виртуалка хреново совмещаются. Так что не велика потеря. Ну, или прийдется изобретать новые приципы работы с вируалкой. Я лично пока что их не вижу.


Ну давай обсудим. В принципе, ведь из перечисленных мной подходов — даже норма типа "мы настоятельно стараемся не разожраться более чем на 3/4 RAM" практически гарантированно спасёт систему одного главного приложения, не так ли?
The God is real, unless declared integer.
Re[9]: С++ culture
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 07.04.08 06:49
Оценка:
Здравствуйте, remark, Вы писали:

VD>>Все же Ява и С++ это языки исповедующие разные парадигмы. Ява компонентный и динамический язык с минималистическим синтаксисом, а С++ статический (не компонентный) и монструозный.

R>

R>С++ — статический язык, со статической типизацией, потому что С++ программы зачастую пишуться, что бы выполняться без присутствия программиста.


А что, для Java он должен постоянно крутить ручку? ;))
The God is real, unless declared integer.
Re[6]: С++ culture
От: remark Россия http://www.1024cores.net/
Дата: 07.04.08 07:18
Оценка:
Здравствуйте, anton_t, Вы писали:

_>Здравствуйте, Cyberax, Вы писали:


C>>sch wrote:


>>> Соответственно, больше всего пугает самое новое и необычное: например,

>>> чаще всего у C++ программистов нарекания вызывает GC из .NET. /Боже
>>> мой, он будет лазить по моим структурам когда ему захочется, и будет
>>> освобождать память! Сам!/

C>>Это-то фигня. Больше всего раздражает, что GC уничтожает память

C>>недетерминировано. А значит RAII и подобные идиомы не проходят.

_>Касательно RAII: что вы делаете с исключениями в деструкторах?



Если я правильно понял, вопрос касательно С++.
В С++ исключения в деструкторах не генерируют.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: С++ culture
От: anton_t Россия  
Дата: 07.04.08 18:14
Оценка:
Здравствуйте, remark, Вы писали:

R>Здравствуйте, anton_t, Вы писали:


_>>Здравствуйте, Cyberax, Вы писали:


C>>>sch wrote:


>>>> Соответственно, больше всего пугает самое новое и необычное: например,

>>>> чаще всего у C++ программистов нарекания вызывает GC из .NET. /Боже
>>>> мой, он будет лазить по моим структурам когда ему захочется, и будет
>>>> освобождать память! Сам!/

C>>>Это-то фигня. Больше всего раздражает, что GC уничтожает память

C>>>недетерминировано. А значит RAII и подобные идиомы не проходят.

_>>Касательно RAII: что вы делаете с исключениями в деструкторах?



R>Если я правильно понял, вопрос касательно С++.

R>В С++ исключения в деструкторах не генерируют.

А если их генерирует вызываемая в деструкторе функция?
Re[8]: С++ culture
От: _nn_ www.nemerleweb.com
Дата: 07.04.08 18:23
Оценка:
Здравствуйте, anton_t, Вы писали:

<skip/>

_>А если их генерирует вызываемая в деструкторе функция?


После того как вы стреляте в ногу себе, вы еще хотите и ходить ?

Просто оберните все в try-catch(...) и исключение не вылетит.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[9]: С++ culture
От: anton_t Россия  
Дата: 07.04.08 18:27
Оценка:
Здравствуйте, _nn_, Вы писали:

__>Здравствуйте, anton_t, Вы писали:


__><skip/>


_>>А если их генерирует вызываемая в деструкторе функция?


__>После того как вы стреляте в ногу себе, вы еще хотите и ходить ?


__>Просто оберните все в try-catch(...) и исключение не вылетит.


Понятно, глотать и логгировать. Я думал может кто что-нибудь умнее знает. А с "стреляете в ногу я не согласен". Разве ошибка при освобождении ресурса это такое уж редкое явление?
Re[8]: С++ culture
От: remark Россия http://www.1024cores.net/
Дата: 07.04.08 18:29
Оценка:
Здравствуйте, anton_t, Вы писали:

_>Здравствуйте, remark, Вы писали:


R>>Здравствуйте, anton_t, Вы писали:


_>>>Здравствуйте, Cyberax, Вы писали:


C>>>>sch wrote:


>>>>> Соответственно, больше всего пугает самое новое и необычное: например,

>>>>> чаще всего у C++ программистов нарекания вызывает GC из .NET. /Боже
>>>>> мой, он будет лазить по моим структурам когда ему захочется, и будет
>>>>> освобождать память! Сам!/

C>>>>Это-то фигня. Больше всего раздражает, что GC уничтожает память

C>>>>недетерминировано. А значит RAII и подобные идиомы не проходят.

_>>>Касательно RAII: что вы делаете с исключениями в деструкторах?



R>>Если я правильно понял, вопрос касательно С++.

R>>В С++ исключения в деструкторах не генерируют.

_>А если их генерирует вызываемая в деструкторе функция?



В С++ такие функции не вызываются в деструкторе. Основной вариант.
Либо исключение ловятся и преобразуется в какую-либо другую форму. Практически не применяемый вариант.
Либо, если это не принципиальная функция, типа логирования, то исключения подавляются.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[10]: С++ culture
От: remark Россия http://www.1024cores.net/
Дата: 07.04.08 19:01
Оценка:
Здравствуйте, anton_t, Вы писали:

_>Здравствуйте, _nn_, Вы писали:


__>>Здравствуйте, anton_t, Вы писали:


__>><skip/>


_>>>А если их генерирует вызываемая в деструкторе функция?


__>>После того как вы стреляте в ногу себе, вы еще хотите и ходить ?


__>>Просто оберните все в try-catch(...) и исключение не вылетит.


_>Понятно, глотать и логгировать. Я думал может кто что-нибудь умнее знает. А с "стреляете в ногу я не согласен". Разве ошибка при освобождении ресурса это такое уж редкое явление?



Может это и не редкое явление, но вызывающий код оно не интересует. Интерфейс деструктора — "Освободить ресурс. Точка.", а не "Возможно освободить ресурс. Если не получиться, то сообщить мне — я сам попробую с этим что-нибудь сделать". Суть в том, что вызывающий код в подавляющем большинстве случаев ничего осмысленного сделать не сможет. Что можно сделать с ресурсом, который больше не нужен, но освободить его не получается?
Можно, конечно, положить ресурс в специальный список для таких ресурсов. И потом попробовать его освободить ещё раз через некоторое время. Но во-первых, это попахивает галиматьёй. А во-вторых, операция добавления в список тоже может провалиться.

Плюс к этому, если операция удаления/отката/освобождения может проваливаться, то в такой ситуации теоретически нельзя строить надёжные системы. Например смотри алгоритм two-phase commit.


А так, в принципе, если хочется "что-нибудь умнее", то в С++ не проблема повторить механизм вложенных исключений. Можно нагородить что-нибудь вроде такого:

class exception
{
public:
    typedef shared_ptr<exception> exception_ptr;

    static void do_throw (exception_ptr ex)
    {
        if (0 == thread_ex)
        {
            thread_ex = ex.get();
            throw ex;
        }
        else
        {
            thread_ex->add(ex);
        }
    }

    ~exception()
    {
        if (thread_ex == this)
            thread_ex = 0;
    }

private:
    static __declspec(thread) exception* thread_ex;
    std::list<exception_ptr> inners;

    void add(exception_ptr inner)
    {
        inners.push_back(inner);
    }
};



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



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.