Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
многопоточность, управление процессами, объекты ядра Windows и т. п.,
если хочешь на уровне писать писать программы для .NET. Помоему нет. Я не прав?


Кто знает, всё что мной перечисленно, это ещё актуально в Windows Vista?
Она случаем уже не виртуальная .NET машина?

Начинаем обсуждать.

On Sat, 22 Oct 2005 17:01:51 +0400, Аноним <0@users.rsdn.ru> wrote:

> Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
> многопоточность, управление процессами, объекты ядра Windows и т. п.,
> если хочешь на уровне писать писать программы для .NET. Помоему нет. Я не прав?

Задай это вопрос своему работодателю.

--
Maxim Yegorushkin

ME>Задай это вопрос своему работодателю.

Окончу ещё два года школы и 5 курсов вуза, устроюсь на работу и задам.

Здравствуйте, Аноним, Вы писали:

А>Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
А>многопоточность, управление процессами, объекты ядра Windows и т. п.,
А>если хочешь на уровне писать писать программы для .NET. Помоему нет. Я не прав?
Мьютексы, многопоточность, управление процессами, объекты ядра Виндовс — это прошлое. Это все уже устарело и не используется.
Что реально используется — это отправка сообщений по именованным каналам в почтовые ящики. Каждая прога заводит себе почтовый ящик на mail.ru и ждет, когда же ей начнут письма прилетать от других прог ну и от Виндовса.

А>Кто знает, всё что мной перечисленно, это ещё актуально в Windows Vista?
А>Она случаем уже не виртуальная .NET машина?
Да, ты прав. Смотри, чтоя сказал выше. На сколько я знаю, Виндовс Виста вообще вся основана на .NET. То есть, вообще говоря, между ними можно поставить знак равенства. Кстати, всем все равно придется учить .NET, потому что Виста даже не будет запускать программы, написанные не для .NET, поэтому учи самый рульный VB.NET, а о си++ и мьютексах даже не думай!
И Java тоже не будет работать на Висте. Почему? Объясняю: маркетинг. Таким образом МС убивает двух зайцев: во-первых, все сразу предпочтут .NET, потому что Джава работать не будет, а во-вторых это нанесет серьезный урон престижу Sun, потому что Джава уже не будет кроссплатформенной (она же на Виндовсе не работает, ха-ха-ха!!!). Короче, считай, что Java мертва.

Вот.


З.Ы.
Не забивай голову сейчас... Еще не известно, что через 7 лет будет, и будет ли этот дотнет жив, когда ты учебу закончишь. Иди лучше девку закадри

...

А>Не забивай голову сейчас...

Спасибо за ответ. . Но как не забивай. Если .NET такая перспективная. то стоит начать учить щас.

А ты не знаешь случаем более менее точной даты выхода релиза VS2005. уж очень хочется на неё взглянуть. особенно на .NET Framework 2.0.

Здравствуйте, <Аноним>, Вы писали:

А>...

А>>Не забивай голову сейчас...

А>Спасибо за ответ. . Но как не забивай. Если .NET такая перспективная. то стоит начать учить щас.

А>А ты не знаешь случаем более менее точной даты выхода релиза VS2005. уж очень хочется на неё взглянуть. особенно на .NET Framework 2.0.

По-моему .NET Framework 2.0 уже давно доступен

Здравствуйте, Аноним, Вы писали:

А>Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
А>многопоточность, управление процессами, объекты ядра Windows и т. п.,
А>если хочешь на уровне писать писать программы для .NET. Помоему нет. Я не прав?


А>Кто знает, всё что мной перечисленно, это ещё актуально в Windows Vista?
А>Она случаем уже не виртуальная .NET машина?

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

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Аноним, Вы писали:

А> Если .NET такая перспективная. то стоит начать учить щас.

"Перспективных" вещей за последние 10 лет придумали массу.
Живы до сих пор 10% (дай Бог).

У одного того же микрософта цепочка ole->com->dcom->com+->.NET чего стОит.

Вот c/c++ жив до сих пор. Без существенных изменений.

Здравствуйте, Аноним, Вы писали:

А>>Не забивай голову сейчас...

А>Спасибо за ответ. . Но как не забивай. Если .NET такая перспективная. то стоит начать учить щас.
А я тебе говорю, не суетись. Блин, как судорога ходячая. Мозги промыли этим чертовым маркетингом. В .НЕТ нет ничего такого особенного и изучить его как два пальца обоссать. Никуда он не денется! Ты лучше математикой и алгоритмированием занимайся. Мозги хорошо развивает. Технологии приходят и уходят, а голова то одна и та навсегда!

А>А ты не знаешь случаем более менее точной даты выхода релиза VS2005. уж очень хочется на неё взглянуть. особенно на .NET Framework 2.0.
Не, не знаю. Ну а бета то уже давно есть. Мне то побоку, я на Си программирую

Здравствуйте, Аноним, Вы писали:

А>Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
А>многопоточность, управление процессами, объекты ядра Windows и т. п.,
А>если хочешь на уровне писать писать программы для .NET. Помоему нет. Я не прав?

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

А>Кто знает, всё что мной перечисленно, это ещё актуально в Windows Vista?
А>Она случаем уже не виртуальная .NET машина?

Случаем не очень.

Здравствуйте, Аноним, Вы писали:

А>З.Ы.
А>Не забивай голову сейчас... Еще не известно, что через 7 лет будет, и будет ли этот дотнет жив, когда ты учебу закончишь. Иди лучше девку закадри

Respect, m8

Здравствуйте, <Аноним>, Вы писали:

А>Мьютексы, многопоточность, управление процессами, объекты ядра Виндовс — это прошлое. Это все уже устарело и не используется.
Даже сейчас эта рухлядь не используется программерами, сошедшими на .NET

А>Что реально используется — это отправка сообщений по именованным каналам в почтовые ящики. Каждая прога заводит себе почтовый ящик на mail.ru и ждет, когда же ей начнут письма прилетать от других прог ну и от Виндовса.
Но мудрый антиспамовый бот мейла.ру банит до 90% подобных писем, ибо неправильная кодировка у атглюка, ответственного за отправку этих системных писем.

А>>Кто знает, всё что мной перечисленно, это ещё актуально в Windows Vista?
А>>Она случаем уже не виртуальная .NET машина?
А>Да, ты прав. Смотри, чтоя сказал выше. На сколько я знаю, Виндовс Виста вообще вся основана на .NET. То есть, вообще говоря, между ними можно поставить знак равенства. Кстати, всем все равно придется учить .NET, потому что Виста даже не будет запускать программы, написанные не для .NET, поэтому учи самый рульный VB.NET, а о си++ и мьютексах даже не думай!
Да, а лучше сразу учи MSIL!
Это тот же ассемблер, только с синтаксисом а-ля Микрософт, и совместимый только с компилятором от Микрософт.
Пиши на MSIL самые быстрые приложения для бизнес-сектора, клиентов БД и обработку пользовательского интерфейса!
Теперь это доступно даже тебе, аноним!

Лохи, пишущие на native-компилируемых компиляторах будут локти себе кусать, видя как легко ты используешь .NET в достижении своих проблем, тогда как им приходится делать в два раза больше действий на их устранение!


А>И Java тоже не будет работать на Висте. Почему? Объясняю: маркетинг. Таким образом МС убивает двух зайцев: во-первых, все сразу предпочтут .NET, потому что Джава работать не будет, а во-вторых это нанесет серьезный урон престижу Sun, потому что Джава уже не будет кроссплатформенной (она же на Виндовсе не работает, ха-ха-ха!!!). Короче, считай, что Java мертва.
Уже даже карманные устройства с логотипом "Совместимо с Microsoft" стало совместимо с .NET, даже клавиатуры и мыши от Микрософта. Без использования .NET это просто немыслимо!
.NET решает все проблемы, связанные с человеческим фактором, преграждая прокладке между стулом и клавиатурой от Майкрософт допускать исполнение недопустимого кода, ТЕПЕРЬ НЕИСПОЛНИМЫЙ КОД ПРОСТО-НАПРОСТО НЕ ИСПОЛНЯЕТСЯ, ибо неподписанные сборки не подлежат доверию окружению CLR.
Подпиши свою сборку всего за $199 и твой код станет ИСПОЛНЯЕМЫМ!

А>Вот.
Ага!

А>З.Ы.
А>Не забивай голову сейчас... Еще не известно, что через 7 лет будет, и будет ли этот дотнет жив, когда ты учебу закончишь. Иди лучше девку закадри
Только не забудь девке пообещать, как всё будет хорошо, ибо с Майкрософтом у тебя всё будет ХОРОЩО!

Здравствуйте, Аноним, Вы писали:

А>Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
А>многопоточность, управление процессами, объекты ядра Windows и т. п.,
А>если хочешь на уровне писать писать программы для .NET. Помоему нет. Я не прав?

А>Кто знает, всё что мной перечисленно, это ещё актуально в Windows Vista?
А>Она случаем уже не виртуальная .NET машина?

А>Начинаем обсуждать.

Конечно не прав. Если .Net скрывает от тебя вызовы api — это вовсе не означает, что она освобождает вас от знания механизмов.

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

Здравствуйте, <Аноним>, Вы писали:

А>Окончу ещё два года школы и 5 курсов вуза, устроюсь на работу и задам.

Тогда точно не актуальна. Через 7 лет все может оказаться ой как по другому.

Здравствуйте, <Аноним>, Вы писали:

А>З.Ы.
А>Не забивай голову сейчас... Еще не известно, что через 7 лет будет, и будет ли этот дотнет жив, когда ты учебу закончишь. Иди лучше девку закадри

Правильно. И на этом основании пусть забьет себе голову убогим ВыньАПИ за проектирование которого руки мало потрывать.

Здравствуйте, <Аноним>, Вы писали:

А>А ты не знаешь случаем более менее точной даты выхода релиза VS2005. уж очень хочется на неё взглянуть. особенно на .NET Framework 2.0.

Framework 2 Final

Автор: Малич Юрий
Дата: 28.10.05

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

J>Многопоточность с сопутствующими ей проблемами синхронизации никуда не денется, каким бы языком, фреймворком и осью ты ни пользовался.
J>Если ты не собираешься писать исключительно однопоточные программы, конечно.

Очень даже денется. Следующие 7 лет как раз эта проблема будет очень активно решаться.

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

J>Был у меня знакомый дельфист. Он принципиально не разбирался с механизмами, а дергал компонентны из сети и крайне наивным образом использовал многопоточность и т.д. Его системы глючили всегда и он всегда ругал win последними словами.

И что характерно, хотя я знаю ВыньАПИ довольно хорошо, но готов ругать его не меньше твоего Дельфиста.

wrote:
>
> Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
> многопоточность, управление процессами, объекты ядра Windows и т. п.,
> если хочешь на уровне писать писать программы для .NET. Помоему нет. Я
> не прав?

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

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

> Кто знает, всё что мной перечисленно, это ещё актуально в Windows Vista?
> Она случаем уже не виртуальная .NET машина?

Нет, не она. Vista это XP с разнообразными улучшениями.

Dair wrote:
>
> А> Если .NET такая перспективная. то стоит начать учить щас.
>
> "Перспективных" вещей за последние 10 лет придумали массу.
> Живы до сих пор 10% (дай Бог).
>
> У одного того же микрософта цепочка ole->com->dcom->com+->.NET чего стОит.
>
> Вот c/c++ жив до сих пор. Без существенных изменений.

C++ за эти 10 лет изменился ничуть не меньше

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

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

J>>Был у меня знакомый дельфист. Он принципиально не разбирался с механизмами, а дергал компонентны из сети и крайне наивным образом использовал многопоточность и т.д. Его системы глючили всегда и он всегда ругал win последними словами.

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

Симптоматично?..

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

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

J>>Многопоточность с сопутствующими ей проблемами синхронизации никуда не денется, каким бы языком, фреймворком и осью ты ни пользовался.
J>>Если ты не собираешься писать исключительно однопоточные программы, конечно.

VD>Очень даже денется. Следующие 7 лет как раз эта проблема будет очень активно решаться.

Она решается вот уже последнии лет 30 — 40, а воз и ныне там — самое революционное изобретение, которое произошло на этом поприще, это введение Эдсгаром Дейкстрой считающего семафора в 1968 году! Так что думаю и в ближайшие 7 лет ничего кардинального не придумают. Как синхронизировали семафорами, так и будем синхронизировать... Как рисовали фишечки на диаграммах многопоточности, так и будем рисовать... И .NET тут ничем не поможет...


Для автора поста (не знаю как вас по имени):
в вашем нынешнем возрасте, лучше не забивать себе голову ни WinAPI, ни .NET`ом — это ещё успеется, а может наоборот не успеется (к тому моменту, как вы закончите обучение — это всё может уже умереть), а, как правильно сказали, выучить математику, алгоритмизацию и банальную архитектуру ЭВМ. Покопайтесь в ассемблере — потом вы этого уже сделать не сможете (времени не будет), а приготиться знания низкого уровня могут очень сильно для дальнейшего понимания работы высоких технологий и архитектур.

Mr. None wrote:

> Она решается вот уже последнии лет 30 — 40, а воз и ныне там — самое
> революционное изобретение, которое произошло на этом поприще, это
> введение Эдсгаром Дейкстрой считающего семафора в 1968 году!

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

DK>Лохи, пишущие на native-компилируемых компиляторах будут локти себе кусать, видя как легко ты используешь .NET в достижении своих проблем, тогда как им приходится делать в два раза больше действий на их устранение!

достижение проблем — это круто

J>Многопоточность с сопутствующими ей проблемами синхронизации никуда не денется, каким бы языком, фреймворком и осью ты ни пользовался.
J>Если ты не собираешься писать исключительно однопоточные программы, конечно.

мне почему-то кажется, что с появлением CELL в конце концов будут выпускать компиляторы, автоматически шинкующие код на потоки,
и подход к многопоточности СИЛЬНО изменится (проблема, не пропав, перейдёт в другую плоскость)

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

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

J>>Был у меня знакомый дельфист. Он принципиально не разбирался с механизмами, а дергал компонентны из сети и крайне наивным образом использовал многопоточность и т.д. Его системы глючили всегда и он всегда ругал win последними словами.

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

Не сказать чтобы я был WinApi гуру, но при разработке ругал пока только себя за нерадивость.

Здравствуйте, Mr. None, Вы писали:

MN>Она решается вот уже последнии лет 30 — 40, а воз и ныне там

Она решается очень вяло, так как массовому рынку это не нужно. Для не массового рынка решеения давно есть.

MN> — самое революционное изобретение, которое произошло на этом поприще, это введение Эдсгаром Дейкстрой считающего семафора в 1968 году!

Да, нет. Это ты остановился на 68-ом году. А наука давно ушла вперед.

MN> Так что думаю и в ближайшие 7 лет ничего кардинального не придумают.

Ну, что же. Подождем. Время рассудит.

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

OT>мне почему-то кажется, что с появлением CELL в конце концов будут выпускать компиляторы, автоматически шинкующие код на потоки,
OT>и подход к многопоточности СИЛЬНО изменится (проблема, не пропав, перейдёт в другую плоскость)

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

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

J>Не сказать чтобы я был WinApi гуру, но при разработке ругал пока только себя за нерадивость.

Ничго. Со временем это иногда проходит.

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

условия такие... Запоминашь текущий режим, перебираешь перключашь режим склаживания, выводишь месседжбокс (чтобы увидить результат). В конце востанавливашь исходный режим. Под режимами я понимаю: "Выключено", "Стандратный", ClearType.

Засеки время, а потом покажешь нам это время и опишешь свои эмоции. А потом я опишу как я вижу это АПИ и сколько времени уйдет у меня на тот же пример.

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

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

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

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

J>>Не сказать чтобы я был WinApi гуру, но при разработке ругал пока только себя за нерадивость.

VD>Ничго. Со временем это иногда проходит.

VD>Ради хохмы попробуй засечь время которое тебе потребуется, чтобы написать программку последовательно переключающую режим сглаживания шрифтов в Windows XP.

VD>условия такие... Запоминашь текущий режим, перебираешь перключашь режим склаживания, выводишь месседжбокс (чтобы увидить результат). В конце востанавливашь исходный режим. Под режимами я понимаю: "Выключено", "Стандратный", ClearType.

VD>Засеки время, а потом покажешь нам это время и опишешь свои эмоции. А потом я опишу как я вижу это АПИ и сколько времени уйдет у меня на тот же пример.

Я тебе уже написал эту прогу (мессага пока висит в ожидании отправки в янусе, посему ссылку дать прям ща не могу). Заняло по прикидкам: ~3 сек — запуск сюхи. ~5-10 сек — запуск MSDN, ~30-60 сек поиск в нем где же в нужной функции описания нужных констант. 60-90 сек набор проги. компиляцию — не засекал. мат в сторону отсутствия в комплекте .h моей старенькой 6-й сюхи пары требуемых констант. ~n — выковыривание нужного .h с 7-й сюхи с рабочего компа + прописание их define-ами в прогу. компиляция. ~3 сек — первая поптыка исправления бага MS (передача константы вместо адреса на нее — задокументированный баг (фича) в части WinAPI функций. кто то в микрософт сильно любит такой метод передачи параметров), компиляция — готово.
сам прикинь сколько получилось.

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

CC>Я тебе уже написал эту прогу (мессага пока висит в ожидании отправки в янусе, посему ссылку дать прям ща не могу). Заняло по прикидкам: ~3 сек — запуск сюхи. ~5-10 сек — запуск MSDN, ~30-60 сек поиск в нем где же в нужной функции описания нужных констант. 60-90 сек набор проги. компиляцию — не засекал. мат в сторону отсутствия в комплекте .h моей старенькой 6-й сюхи пары требуемых констант. ~n — выковыривание нужного .h с 7-й сюхи с рабочего компа + прописание их define-ами в прогу. компиляция. ~3 сек — первая поптыка исправления бага MS (передача константы вместо адреса на нее — задокументированный баг (фича) в части WinAPI функций. кто то в микрософт сильно любит такой метод передачи параметров), компиляция — готово.
CC>сам прикинь сколько получилось.

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

Я вот убил добрый час пока разобрался во всем этим барахлом.

Так вот теперь можешь сравнить этот трах с использованием человеческого АПИ

Автор: VladD2
Дата: 01.11.05

в котором и хэлп то читать не нужно.

Мне нужно знать только имя класса, нажать "." и вписать "F". Далее комплит подскажет мне имя свойства. Далее когда я напишу "=" мне будет выдан список вариантов. В итоге вместо:

DWORD smoothType = FE_FONTSMOOTHINGCLEARTYPE;
SystemParametersInfo (SPI_SETFONTSMOOTHING, TRUE, NULL, 0);
SystemParametersInfo (SPI_SETFONTSMOOTHINGTYPE, 0, 
  (void*)FE_FONTSMOOTHINGCLEARTYPE, 
    SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);

Мне достаточно написать:

SysInfo.FontSmoothingType = FontSmoothingType.ClearType;

Причем ненужен ни хэлп, ни копипэст. Все делается комплитом и подсказками при вводе.

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

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

VD> Я вот убил добрый час пока разобрался во всем этим барахлом.
виноват кто? тот кто против задокументированного в описании API написал хак...

VD> Так вот теперь можешь сравнить этот трах с использованием человеческого АПИ

Автор: VladD2
Дата: 01.11.05

в котором и хэлп то читать не нужно.

мне всегда не нравились такие API (вернее обертки) тем, что они скрывают происходящие на самом деле процессы. Если бы это был родной API системы — тогда да, другое дело.
А с WinFX проблема не в том что API переделан, проблема в том, что использование этого API ограничивается искусственно только managed вызовами.

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

CC>мне всегда не нравились такие API (вернее обертки) тем, что они скрывают происходящие на самом деле процессы.

А что тут скрывается? АПИ (я уже о моем варианте) декларирует, что позволяет узнать или переключить сглаживание. Оно честно выполняет свое предназначение.

Ты просто привык к кривым оберткам к кривым АПИ. Собственно будь АПИ примям и обертки бы не понадобились бы. Ну, или были бы совсем простенькими.

CC>Если бы это был родной API системы — тогда да, другое дело.

Дык я и говорю, что ВыньАПИ прив, и что чтобы не быть кривым ему нужно выглядеть приблизительно "так".

CC>А с WinFX проблема не в том что API переделан, проблема в том, что использование этого API ограничивается искусственно только managed вызовами.

Вот мне и странно, что почему-то АДО.НЕТ дергать из неуправляемого кода желения нет, а Индигу — есть.

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

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

MN>>Она решается вот уже последнии лет 30 — 40, а воз и ныне там

VD>Она решается очень вяло, так как массовому рынку это не нужно. Для не массового рынка решеения давно есть.

Где-то я это уже слышал....
"Java и C++ так популярны потому что за ними стоят крупные корпорации. За Обероном их нет!" — цититрование вольное, но я думаю вы поняли о чём я .

MN>> — самое революционное изобретение, которое произошло на этом поприще, это введение Эдсгаром Дейкстрой считающего семафора в 1968 году!

VD>Да, нет. Это ты остановился на 68-ом году. А наука давно ушла вперед.

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

MN>> Так что думаю и в ближайшие 7 лет ничего кардинального не придумают.

VD>Ну, что же. Подождем. Время рассудит.

Ок, через 7 лет я вас найду и напомню вам ваши слова .

OnThink wrote:

> мне почему-то кажется, что с появлением CELL в конце концов будут
> выпускать компиляторы, автоматически шинкующие код на потоки, и подход
> к многопоточности СИЛЬНО изменится (проблема, не пропав, перейдёт в
> другую плоскость)

В VS 2005 уже есть такая поддержка в виде OpenMP для С++. Другое
дело, что в императивных языках компилятор сам не может определить
семантику многих используемых переменных и ее приходится явно прояснять
(в OpenMP с помощью #pragma). Так что, я думаю, мы вскоре увидим большее
распространение функционального стиля.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

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

J>>Не сказать чтобы я был WinApi гуру, но при разработке ругал пока только себя за нерадивость.

VD>Ничго. Со временем это иногда проходит.

VD>Ради хохмы попробуй засечь время которое тебе потребуется, чтобы написать программку последовательно переключающую режим сглаживания шрифтов в Windows XP.

Offtop

Вопрос был вот в чем:

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

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

Здравствуйте, Mr. None, Вы писали:

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

1. Использование неизменяемых объектоы.
2. Комуникация между объектами с помощью неизменяемых сообщений.
3. Повышение декраративности в программировании.

MN> Это не наезд, не проверка знаний, я просто хочу узнать — может и вправду есть что-нибудь революционное, что я упустил (только не упоминайте активных объектов — они уже оскомину набили, а толку с них весьма мало).

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

MN>Ок, через 7 лет я вас найду и напомню вам ваши слова .

Не забудь.