Объясните для незнающего человека.
Какие недостатки у .NET? Можно ли работать
с WinAPI? Имеет ли смысл переходить с
Borland C++Builder? Сложно ли это будет?
Вот так много вопросов...

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

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

А>Объясните для незнающего человека.
А>Какие недостатки у .NET?

Многие относят к недостаткам:
1. То что на клиентских машинах нужно ставить .NET Framework
2. То что .NET-приложения в целом более требовательны к ресурсам чем приложения с той же функциональностью, написанные на C++/VB итп.

А>Можно ли работать с WinAPI?

Можно — используя PInvoke.
Из моего опыта могу сказать что во многих случаях тебе не обойтись без использования WinAPI. Хотя базовая функциональность реализуется управляемым кодом, когда хочется что-то особенное — часто приходится обращаться к WinAPI.

А>Имеет ли смысл переходить с Borland C++Builder? Сложно ли это будет?

Тебе самому решать — стоит или нет. Если C++ знаешь — особых проблем с переходом на C# не будет. Основные проблемы — изучить основы, изучить многочисленные и обширные библиотеки.

А>Вот так много вопросов...

Это не много — много будет когда начнешь...

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

N>1. То что на клиентских машинах нужно ставить .NET Framework

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

N>2. То что .NET-приложения в целом более требовательны к ресурсам чем приложения с той же функциональностью, написанные на C++/VB итп.

Это факт — "managed" код ясен кучу всего при выполнении вокруг себя "строит".

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


А>>Имеет ли смысл переходить с Borland C++Builder? Сложно ли это будет?

С прицелом на будущее — да. Если будут этот язык продвигать и ЛонгХорн на нем "пописывать".
Сам сейчас сижу, изучаю. До этого на C++Builder 5 лет, и на студии периодически ))
Изучение начал со спецификации ECMA 334.
Библиотека визуальных компонентов в дот.нет напоминает очень VCL. Много похожестей всяких, потому
писать визуальные части не сложно совсем. В среде есть и обжект инспектор и все такое... Хотя Visual C# 2005 Express Edition Beta на порядок
неудобнее, ИМХО. (возможно я просто очень привык к среде билдера, потому помидорами не кидать!)
А вот с остальными классами FCL — немного сложнее Изучать кто-что делает приходится...


зы: понравилось то, что строки теперь все в юникоде

Hello, temofey!

N>> 1. То что на клиентских машинах нужно ставить .NET Framework

t> На сколько мне известно не обязательно...есть в поставке что-то,
t> работающее из коммандной строки способдное перелапатить исходник и
t> сделать его не требовательным с .NET Framework (сам не смотрел, но один
t> уважаемый человек сегодня поведал)...

Можешь его больше не уважать Обманул он тебя.

WBR, Igor Evgrafov.

Какие недостатки у .NET?

Очень хочется написать — отсутствуют! Но увы... Это не совсем так, пока. А для их обсуждения надо плясать не от НЕТ-вообще, а от НЕТ-для конкретной задачи. Ибо любое(практически) св-во платформы в приложении к конретной проблеме легко меняет свой знак с + на — и так же легко обратно.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

nzeemin wrote:

> А>Объясните для незнающего человека.
> А>Какие недостатки у .NET?
>
> Многие относят к недостаткам:
> 1. То что на клиентских машинах нужно ставить .NET Framework
> 2. То что .NET-приложения в целом более требовательны к ресурсам чем
> приложения с той же функциональностью, написанные на C++/VB итп.

Еще можно добавить:
3. Проект получается почти Open Source, т.к. средства
дизассемблирования .NET программ рулят (получаешь полный, ну или почти
полный код всего приложения)

--
WBR, Denis Basargin
ICQ: 33681277
Mail: sailorman(at)rin.ru
Origin: Hедовольные были, но мы их пофиксили

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

S> Еще можно добавить:
S> 3. Проект получается почти Open Source, т.к. средства
S>дизассемблирования .NET программ рулят (получаешь полный, ну или почти
S>полный код всего приложения)

Ну, обфускаторы мгут сильно попрортить радость от опенсорсности. Я тут на одну игрушку поглядел. Декомпилироваться то она декомпилируется, но радости от этих всех клсс a свойство b никакой. Как в том анекдотке:

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

Думаю если дело того стоит, то и с классом A, и со свойством B можно разобратсья; и "забить", так сказать, на радости. Вот в чём вся вся проблема!

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

AP> Думаю если дело того стоит, то и с классом A, и со свойством B можно разобратсья; и "забить", так сказать, на радости. Вот в чём вся вся проблема!

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

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

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

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

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

AP>> Думаю если дело того стоит, то и с классом A, и со свойством B можно разобратсья; и "забить", так сказать, на радости. Вот в чём вся вся проблема!

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

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

Только такая вот проблемка: если кто-то хитрый решит скоммуниздить полезный кусочек кода из моей программули, то он это сделает тупым копированием всех этих а и б. Выдерет для себя "чёрный ящик". После чего глобальной заменой подправит пару имён на более удобные. И получается, что я своим кодом (кровью и потом ) кормлю потенциальную армию халявщиков? Кроме того, это сейчас обфускаторы выдают нечто нечитаемое... А потом энтузиасты "утирательства носа мелкософту" напишут тулзы, позволяющие ускорить разбор кода — закономерности всякие откопают, связи будут наглядно показывать и тэ пэ.

Значит, потребуется придумывать новые способы защиты? Вставлять в каждый более-менее обособленный кусок кода всяческие хитрости, чтоб он не смог работать в отрыве от всей программы? А если я этот код захочу потом сам использовать?

Да, и ещё, не могу понять: почему-то в эру становления дотнета все громко кричали: нет, двелопер, тебе не нужно будет менять любимый язык! Пиши на C++! Пиши на Дельфе! Пиши на чём хочешь, всё скомпилится в дотнет! А теперь как-то забыли об этом, теперь "говорим дотнет — подразумеваем C#"... Что за фигня?

З.Ы.Не пинайте в случае чего, не дотнетчик я пока...
З.З.Ы. Нет, вы представьте — фактически ЛонгХорн пойдёт в исходниках?!!

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

VD>А ты не думай. Ты попробуй разобраться.
А что там разбираться , если код компилится берешь в руки C#Refactory И начинаешь class A называть для начала ClassA и всё становиться понятно.
VD>Многие из тех кто попробовали пришли к выводу, что проще написать код самому чем разгадывать шарады.
Слабые нервы

p/s/ Некоторые обфускаторы еще добавляют IL конструкции, при виде которых ildasm падает

Кстати, насчет "если знаешь Цпп, то на C# перейти очень просто"... А вот нифига подобного! Многие "проблемы" возникают именно у тех, кто переходит с Цпп. Они просто не понимают простоты и мощности C#.

Легко переходят Дельфийцы! Создатель-то тот же!

—

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

А>Легко переходят Дельфийцы! Создатель-то тот же!

При чем здесь бордерланд?

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

А>Многие "проблемы" возникают именно у тех, кто переходит с Цпп. Они просто не понимают простоты и мощности C#.

Да нет, скорее наоборот понимают, но не простоту и мощность, а ущербность и #$@нутость...
Извините, пока читал терпел сколько мог, но всё равно не смог удержаться от комментария...

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

А>Объясните для незнающего человека.
А>Какие недостатки у .NET? Можно ли работать
А>с WinAPI? Имеет ли смысл переходить с
А>Borland C++Builder? Сложно ли это будет?
А>Вот так много вопросов...

NET прекрасно ложится на масштабируемые решения + Internet(Intranet). Для таких приложений, там очень много сделано. Достаточно много сделано для создания приложений корпоративного уровня.

Клиент-сервер — значительно удобнее Delphoвые среды. В первое время, при создании тестовой программы для подобной задачи, вспоминал великий и могучий. Естественно, после этого проект делался на другой платформе (Delphi).
Для системных утилит — слишком большие требования к ресурсам.

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

С уважением, Gleb.

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

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

Я вообще не считаю необходимым что-то прятать. Если ты изобрел гиниальный алгоритм (что сомнительно, но все же), то запатентуй его. А иначе что прятать то?

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

Приимущества тут только при вскрытии защит. А они сами по себе бред. И с их семом нет проблем и в анменеджед-коде. Блыло бы зачем это делать.

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

GA>Только такая вот проблемка: если кто-то хитрый решит скоммуниздить полезный кусочек кода из моей программули, то он это сделает тупым копированием всех этих а и б. Выдерет для себя "чёрный ящик".

Он не хитрый. Он тупой. Это все равно что бомбу с часовым механизмом заложить под свой офис.

GA> После чего глобальной заменой подправит пару имён на более удобные.

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

GA> И получается, что я своим кодом (кровью и потом ) кормлю потенциальную армию халявщиков? Кроме того, это сейчас обфускаторы выдают нечто нечитаемое... А потом энтузиасты "утирательства носа мелкософту" напишут тулзы, позволяющие ускорить разбор кода — закономерности всякие откопают, связи будут наглядно показывать и тэ пэ.

МС тут вообще не причем. Они обфускаторы не делают и не используют. Тулзы такие тоже нельзя создать.

GA>Да, и ещё, не могу понять: почему-то в эру становления дотнета все громко кричали: нет, двелопер, тебе не нужно будет менять любимый язык! Пиши на C++! Пиши на Дельфе! Пиши на чём хочешь, всё скомпилится в дотнет! А теперь как-то забыли об этом, теперь "говорим дотнет — подразумеваем C#"... Что за фигня?

Собственно это офтоп, но отвечу. Кто такое говорит? Просто большинство комьюнити пишет на Шарпе. Почему? Да удобно.

GA>З.З.Ы. Нет, вы представьте — фактически ЛонгХорн пойдёт в исходниках?!!

В ЛХ менеджед-кода будет процента 2. В "исходниках" пойдет то что и так всю жизь не пряталось. Будет только проще искать ошибки и создавать более красивые решения. Так что тут декомпилируемость дотнета только на руку. Причем на руку и нам, и МС.

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

VP>А что там разбираться , если код компилится берешь в руки C#Refactory И начинаешь class A называть для начала ClassA и всё становиться понятно.

Ну, флаг тебе в руку если тебе понятно что такое ClassA.

VP>p/s/ Некоторые обфускаторы еще добавляют IL конструкции, при виде которых ildasm падает

ildasm вообще никого не интересует. Да и обойти такие приколы можно. Это как раз хреновая защита. Защита от случайного зеваки.

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

BTA>Кстати, насчет "если знаешь Цпп, то на C# перейти очень просто"... А вот нифига подобного! Многие "проблемы" возникают именно у тех, кто переходит с Цпп. Они просто не понимают простоты и мощности C#.

BTA>Легко переходят Дельфийцы!

Наше голосование показало

Автор: VladD2
Дата: 14.10.04
Вопрос: Какие языки программирования вы использовали наиболее интенсивно до того как перешли на .NET.
Просьба отвечать только тех кто в данный момент интенсивно использует дотнет и его языки.

, что большая часть перешедших как раз С++-ники.

BTA>Создатель-то тот же!

Слава Исусу.

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

MN>Да нет, скорее наоборот понимают, но не простоту и мощность, а ущербность и #$@нутость...
MN>Извините, пока читал терпел сколько мог, но всё равно не смог удержаться от комментария...

Ну, это только ущербные и #$@ные... Шутка.

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

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

BTA>>Кстати, насчет "если знаешь Цпп, то на C# перейти очень просто"... А вот нифига подобного! Многие "проблемы" возникают именно у тех, кто переходит с Цпп. Они просто не понимают простоты и мощности C#.

BTA>>Легко переходят Дельфийцы!

VD>Наше голосование показало

Автор: VladD2
Дата: 14.10.04
Вопрос: Какие языки программирования вы использовали наиболее интенсивно до того как перешли на .NET.
Просьба отвечать только тех кто в данный момент интенсивно использует дотнет и его языки.

, что большая часть перешедших как раз С++-ники.
Посчитай, сколько народу учило или учат в институтах C++ и сколько Delphi. И не очень нравится глагол "переходят". Такое впечатление что они нажимают какую-то кнопку, Стереть файл: Спецификация С++ Yes No. Кстати, радуют двое человек, которые перешли с ASM. Все ребята, assembler умирает, да здраствует NET.

BTA>>Создатель-то тот же!
Легче всего тем кто на Java. Концепция та же.

И вообще, спецификацию языка выучить значительно легче и не важно С# или VB. Значительно труднее понять NET.

С уважением, Gleb.

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

GZ>Посчитай, сколько народу учило или учат в институтах C++ и сколько Delphi. И не очень нравится глагол "переходят". Такое впечатление что они нажимают какую-то кнопку, Стереть файл: Спецификация С++ Yes No.

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

GZ> Кстати, радуют двое человек, которые перешли с ASM. Все ребята, assembler умирает, да здраствует NET.



BTA>>>Создатель-то тот же!
GZ>Легче всего тем кто на Java. Концепция та же.

Ага. А еще легче тем кто на ВБ. Принципы то те же...
Не смешно? Дотнет вообще не привязан к языку. Если уж говорить, то о Шарпе. А Шарп впитал в себя целую тучу концепций из кучи языков. Из Явы конечно не мало, но и из Дельфи тоже. Да и из плюсов кучу. Более того ВБ + Дельфи + С++ полностью перекрывают возможности Явы. Ява появилас позже чем все эти языки. Так что спор о том кто у гого что перенял не очень осмысленный.

Просто всем. Просто потому, что в Шарп грамотно спроектирован. И потому что в нем встречаются знакомые концепции. Так же сложно всем, так как Шарп отличается от всех перечисленных языков. С++ непонятно как можно жить без множественного наследования. Дельфисту что такое ArrayList. Явщику что такое делекаты. Ну, и т.п.

GZ>И вообще, спецификацию языка выучить значительно легче и не важно С# или VB. Значительно труднее понять NET.

Гы. А спецификация то у Шарпа посложнее чем у С++. Выучить ее на изусть не так то просто. Тут в другом дело. Она содержит меньше заморочек и больее однозначана. Это приводит к тому, что ее ненужно заучивать. Она в основном интуитивно понятна.

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

VD>Гы. А спецификация то у Шарпа посложнее чем у С++.
Ну вот я этого не понимаю. Что значит сложнее? Более объемная контекстно-свободная грамматика? Дак это еще ни о чем не говорит. Вернее говорит. Говорит, что С# легче поддается для формализации в виде контекстно-свободной грамматики. ИМХО, это может означать, что С# проще. (а может и не означать )

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


VD>Просто потому, что Шарп грамотно спроектирован.
Вот уж поспорил бы я с вами по этому поводу, да времени нет. Могу только пример привести:
0 — это ноль типа int;
DataRow хранят элементы в виде object;
запись row[0] = 0 означает, что в 0-вую колонку строки заносится нулевое значение типа int;
ВНИМАНИЕ, а если 0-вая колонка в базе имеет тип соответствующий шарповскому decimal мы имеем ошибку периода исполнения! В простейшем случае, когда запись в DataRow приводит к записи в базу, найти такой косяк просто. А вот в моём случае система имела 3-ёх звенную архитектуру и запись данных в контейнер (DataSet) происходило на одном конце, а сброс этого контейнера в базу — на другом, между ними был ASP.NET и ремоутинг. Если бы вы знали, как я задолбался вылавливать такие косяки, посто потому что постоянно забывали писать 0m (0 типа decimal) и писали 0 (0 типа int — почувствуй разницу). В данном случае ущерб от срезки при нявном приведении типов был бы и того меньше — в конце концов, можно было бы бросать исключении только при срезке, а во всех остальных случаях пропускать преобразование (в нашем случае это тоже бы подошло, потому что руками мы инициализировали только нулевые значения)... А наличие шаблонов или по крайней мере контроля типов при выполнении в самой строке (в непосредственной близости от точки неверной инициализации) было бы совсем идеальным. Это не ошибка в архитектуре приложения — это пример неграмотного проектирования самого языка и его библиотеки.

VD>И потому что в нем встречаются знакомые концепции.

VD>Так же сложно всем, так как Шарп отличается от всех перечисленных языков. С++ непонятно как можно жить без множественного наследования.
Вот отсутсвие множественного наследования — это последнее, что мне мешало пользоваться Шарпом. А на первых 3-ёх местах было:
1) отсутствие шаблонов — только не надо поднимать флейм на тему, что можно и без шаблонов обойтись — не всегда можно — или что в спецификации шарпа 2.0 шаблоны уже есть — это не те шаблоны, они слишком ущербны;
2) обработка ошибок через сброс исключений в сочетании с отсутствием RAII — я уже говорил на эту тему, почему нельзя было разрешить деструкторы у размерных типов;
3) отсутствие друзей — иногда бывает нужно одному классу или функции предоставить доступ к некоторым закрытым полям класса, модификатор internal с этим не справляется, написание соответствующего атрибута тоже не пойдёт — я хочу знать, что я не прав при компиляции, а не при демонстрации у заказчика.

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

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

GZ>>Посчитай, сколько народу учило или учат в институтах C++ и сколько Delphi. И не очень нравится глагол "переходят". Такое впечатление что они нажимают какую-то кнопку, Стереть файл: Спецификация С++ Yes No.

VD>Откровенно говоря не много я знаю народу кто вообще держит спецификацию плюсов под боком.
VD>С другой стороны понятно, что ничего сразу не забывается. Да этого и не нужно. Просто использоваться начинается менее плотно или вообще не используется. Я плюсы в руки за последние два года брал наз 30. И в основном для тестов.
Я знаю достаточно много. Например мы: основная часть написана на Delphi, некоторые системные части на C++, Web на ASP.NET. Есть еще несколько знакомых фирм, с подобными проблемами. На мой взгляд, связка типа Delphi+C++ или NET + C++ оптимальна. Класть некоторые системные вещи на NET не является оптимальным решением.

BTA>>>>Создатель-то тот же!
GZ>>Легче всего тем кто на Java. Концепция та же.

VD>Ага. А еще легче тем кто на ВБ. Принципы то те же...
Например, отсутсвие наследования. Для того чтобы сделать хороший дизайн, разработчику надо будет перестроить мышление.
VD>Не смешно? Дотнет вообще не привязан к языку. Если уж говорить, то о Шарпе. А Шарп впитал в себя целую тучу концепций из кучи языков. Из Явы конечно не мало, но и из Дельфи тоже. Да и из плюсов кучу. Более того ВБ + Дельфи + С++ полностью перекрывают возможности Явы. Ява появилас позже чем все эти языки. Так что спор о том кто у гого что перенял не очень осмысленный.
Абсолютно не осмысленный. Согласись, что на 90% С# как язык зависит от платформы и самой концепции NET. Я бы даже сказал так, С# — это некоторый С++ язык наиболее полно отражающий возможности платформы NET, и в котором убраны концепции не используемые на данной платформе. Еще бы возможность в некоторых отдельных случаях перевести управление boxингом в ручной режим, было бы круто. Хотя я понимаю почему это не было сделано.

VD>Просто всем. Просто потому, что в Шарп грамотно спроектирован. И потому что в нем встречаются знакомые концепции. Так же сложно всем, так как Шарп отличается от всех перечисленных языков. С++ непонятно как можно жить без множественного наследования. Дельфисту что такое ArrayList. Явщику что такое делекаты. Ну, и т.п.
Некоторая поправка. С++ можно жить без множественного наследования (невелика потеря, по опыту знаю что множественным наследованием в своем коде пользовались немногие разработчики, в основном это была пререгатива различных библиотек типа STL, ATL). Значительно важнее отсутсвие ручного управления памятью и указатели. Для Дельфиста понятна что такое ArrayList, есть аналог, но при этом надо сразу сказать что это объект не языка а стандартного объекта (не будем же мы говорить что в VB.NET его нет). Дельфисту труднее понять систему Binding. И им обоим будет непонятно, что такое GC, и отсутсвие детерменированных деструкторов. Про яву не могу ничего сказать, так как не знаю языка. Хотя сразу скажу, что управление памятью весьма похожа. Им не придется менять мышление. Итого, важнее платформа, чем синтаксис.

GZ>>И вообще, спецификацию языка выучить значительно легче и не важно С# или VB. Значительно труднее понять NET.

VD>Гы. А спецификация то у Шарпа посложнее чем у С++. Выучить ее на изусть не так то просто. Тут в другом дело. Она содержит меньше заморочек и больее однозначана. Это приводит к тому, что ее ненужно заучивать. Она в основном интуитивно понятна.
Что касается С# 1.0, то не согласен. То что касается 2.0 умолчу, потому что знаю только по статьям. Вообще у кого больше по объему спецификация вопрос дурацкий. С# за счет отсутсвия ссылок на память в managed коде действительно значительно облегчает ее понимание.

С уважением, Gleb.

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

VD>>Гы. А спецификация то у Шарпа посложнее чем у С++.
V>Ну вот я этого не понимаю. Что значит сложнее? Более объемная контекстно-свободная грамматика?

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

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

MN>DataRow хранят элементы в виде object;

DataRow вобще ничего, кроме ссылки на DataColumn не хранит.

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

AVK>С чего ты взял что у шарпа контекстно-свободная грамматика?
Я этого не говорил. КС грамматика используется для облегчения построения парсера, поскольку в данном случае процесс можно автоматизировать.

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

AVK>>С чего ты взял что у шарпа контекстно-свободная грамматика?
V>Я этого не говорил. КС грамматика используется для облегчения построения парсера, поскольку в данном случае процесс можно автоматизировать.

И? В чем твоя исходная мысль была?

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

AVK>И? В чем твоя исходная мысль была?
В том, что ошибочно делать выводы о сложности КЗ языков на основе КС грамматик, применяемых для построения синтаксических анализаторов этих языков, так как объемная КС грамматика может свидетельствовать о том, что язык лучше поддается формализации КС грамматикой, что само по себе говорит скорее о простоте, нежели о сложности.

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

AVK>>И? В чем твоя исходная мысль была?
V>В том, что ошибочно делать выводы о сложности КЗ языков на основе КС грамматик, применяемых для построения синтаксических анализаторов этих языков, так как объемная КС грамматика может свидетельствовать о том, что язык лучше поддается формализации КС грамматикой, что само по себе говорит скорее о простоте, нежели о сложности.

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

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

AVK>Все равно не понял. О КС-грамматиках речь завел ты. И из своих же слов сделал вывод.
Цитата:

Что значит сложнее? Более объемная контекстно-свободная грамматика?...

То есть мои слова надо понимать так: "Если Влад сделал свой вывод на основе сложности КС грамматики, то это неправильно". Я ни с кем не спорил. Просто высказал мысль. Вот и все. Никакого потайного смысла.

AVK>Сложность же спецификации, о которой говорит Влад, состоит в том, что у шарпа просто больше синтаксических конструкций,
Это само по себе еще ни о чем не говорит.

AVK>и сами конструкции сложнее.
А вот об этом по подробнее. Сложнее, чем что? Чем разрешение перегрузки? Чем ODR? Чем SFINAE? Чем поиск имен в шаблонах (ADL)? Чем частичная специализация шиблонов (правила формального упорядочивания)? Чем виртуальное наследование?
Да по некоторым таким моментам можно отдельные книги выпускать.

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

AVK>>и сами конструкции сложнее.
V>А вот об этом по подробнее. Сложнее, чем что? Чем разрешение перегрузки? Чем ODR? Чем SFINAE? Чем поиск имен в шаблонах (ADL)? Чем частичная специализация шиблонов (правила формального упорядочивания)? Чем виртуальное наследование?
V>Да по некоторым таким моментам можно отдельные книги выпускать.

Это свидетельство не сложности, а запутанности и неоднозначности. Неинтуитивности, если хочешь. Поведение, к примеру, дотнетных событий тоже штука не тривиальная, особенно если разбираться полностью, вплоть до того, как их обрабатывает JIT или маршаллер. Однако знать все это мало кому интересно, поскольку поведение делегата интуитивно понятно. Или вот еще пример — енумы. Сложнее плюсовых просто на порядок. Тем не менее, как правило, программисту это никаких особых проблем не доставляет.

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

MN>0 — это ноль типа int;


MN>DataRow хранят элементы в виде object;
MN>запись row[0] = 0 означает, что в 0-вую колонку строки заносится нулевое значение типа int;

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

MN>Если бы вы знали, как я задолбался вылавливать такие косяки, посто потому что постоянно забывали писать 0m (0 типа decimal) и писали 0 (0 типа int — почувствуй разницу).

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

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

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

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

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

MN> А наличие шаблонов или по крайней мере контроля типов при выполнении в самой строке (в непосредственной близости от точки неверной инициализации) было бы совсем идеальным.

А теперь подумай чья это проблема, языка или того кто писал датасет? Как, по-твоему, трудно было сделать подобную проверку в датастете?

А вот автоматическое приведение при анбоксинге может привести к проблемам в других метах.

Кстати, если нужно автоматическое приведение при анбоксинге, то достаточно использвать методы серии Converter.ToXxxTyoe(). И то что их не использовали в ДатаСете прискорбно, но это никак не является проблемой самого языка.

MN> Это не ошибка в архитектуре приложения — это пример неграмотного проектирования самого языка и его библиотеки.

Ну, выше я вроде все растолковал. Надеюсь доходчиво...

MN>Вот отсутсвие множественного наследования — это последнее, что мне мешало пользоваться Шарпом.

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

MN> А на первых 3-ёх местах было:
MN>1) отсутствие шаблонов — только не надо поднимать флейм на тему, что можно и без шаблонов

Действительно можно. Хотя и действительно неудобно.

MN> обойтись — не всегда можно — или что в спецификации шарпа 2.0 шаблоны уже есть — это не те шаблоны, они слишком ущербны;

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

MN>2) обработка ошибок через сброс исключений в сочетании с отсутствием RAII — я уже говорил на эту тему,

Чуть-чуть попрограммировав на Шарпе станоится очевидным что нет никаких проблем с управлением ресурсами в этом языке. После того как отпадает необходимость управлять освобождением памяти управление другими ресурсами становится детской задачей. Конструкция "using ()" с успехом решает эту задачу.

MN>почему нельзя было разрешить деструкторы у размерных типов;

Потому-что это усложнение языка которое не имеет смысла на практике.

MN>3) отсутствие друзей — иногда бывает нужно одному классу или функции предоставить доступ к некоторым закрытым полям класса, модификатор internal с этим не справляется, написание соответствующего атрибута тоже не пойдёт — я хочу знать, что я не прав при компиляции, а не при демонстрации у заказчика.

Опять таки выдуманная проблема появляющаяся из-за ущербности взгляда С++-ника. Это проблема не языка, а ограничение платформы, или даже технологии. Дотнет компонентная среда. Модификаторы доступа — это средства обеспечения защиты кода. Они работают на уровше модулей (сборок). "Друзья" же есть парадигма которую можно реализовать только в рамках одной сборки. И опять же на практике нет никаких проблем. Так что забивать себе голову вообще ненужными вещами?

В С++ есть еще сотни фич которые можно называть полезными. Но правда в том, чно 99% из них нафиг не нужны и с успехом заменяются другими решениями. Если привнести их все в язык, то язык станет таким же запутанными и монстроидальным как С++.

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

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

GZ>Я знаю достаточно много. Например мы: основная часть написана на Delphi, некоторые системные части на C++, Web на ASP.NET. Есть еще несколько знакомых фирм, с подобными проблемами. На мой взгляд, связка типа Delphi+C++ или NET + C++ оптимальна. Класть некоторые системные вещи на NET не является оптимальным решением.

1. Довольно неразумно противопоставлять С++ дотнету, так как для дотнета без проблем можно писать на С++.
2. В большинстве случае применение С++ мало чего дает. Хотя конечно всегда можно найти задачу где его использование будет более удобное.

VD>>Ага. А еще легче тем кто на ВБ. Принципы то те же...
GZ>Например, отсутсвие наследования. Для того чтобы сделать хороший дизайн, разработчику надо будет перестроить мышление.

Причем тут это? Что по твоему в Шарпе мало похожих с ВБ чер?

GZ>Абсолютно не осмысленный. Согласись, что на 90% С# как язык зависит от платформы и самой концепции NET.

Зачем созлашаться с явно неверными утверждениями? Моно уже полнейшее доказательство неврности этих слов. Да и вообще Шарп нужнается в основном только в GC, а GC реализован в куче рантаймов языков не относящихся в к дотнету.

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

GZ> Я бы даже сказал так, С# — это некоторый С++ язык наиболее полно отражающий возможности платформы NET, и в котором убраны концепции не используемые на данной платформе. Еще бы возможность в некоторых отдельных случаях перевести управление boxингом в ручной режим, было бы круто. Хотя я понимаю почему это не было сделано.

Откровенно гворя с С++ у шарпа общие в основном названия ключевых слов и скобки. Концептуально яыки различаютс очень сильно.

GZ>Некоторая поправка. С++ можно жить без множественного наследования (невелика потеря, по опыту знаю что множественным наследованием в своем коде пользовались немногие разработчики, в основном это была пререгатива различных библиотек типа STL, ATL).

Да без разницы что знакомого ты ненайдешь в Шарпе. Главное что ненайдешь! Так же как без разницы что знакомог ты найдешь в Шарпе.

GZ> Значительно важнее отсутсвие ручного управления памятью и указатели. Для Дельфиста понятна что такое ArrayList, есть аналог, но при этом надо сразу сказать что это объект не языка а стандартного объекта (не будем же мы говорить что в VB.NET его нет).

Его нет в ВБ 6. Да и в ВБ.НЭТ его используют не очень часто (хотя и зря), так как в ВБ есть встроенные динамические массивы.

GZ> Дельфисту труднее понять систему Binding.

Понятия Binding ни в языках дотнета, ни в CLR нет. Это идиома высокоуровневых библиотек. Не мешай мух с котлетами.

GZ> И им обоим будет непонятно, что такое GC, и отсутсвие детерменированных деструкторов.

В Дельфи нет автоматически вызваемых методов очистки. А вызываемые вручную можно реализовать где угодно. Так что Дельфисту тут все будет понятно.

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

И какая Платформа у С++ или Дельфи? Блин, оба языка без проблем используются для создания менеджед-кода. Дельфи так вообще даже серьезных изменений не претерпела, так как концептуально очень близка.

В общем, не нужно выдумывать сказок. Шарп — это сборная солянка со всех императивный языков существовавших до этого. Больше всего Шарп перенял из Явы и ВБ. Но это и это утверждение спорно. Дотнет является рантаймом для Шарпа. Потенциально шарп без проблем можно реализовать и на другом рантайме. Просто это мало кому нужно.

GZ>Что касается С# 1.0, то не согласен.

И давно ты читал спецификацию? Хотя судя по всему ты ее в глаза не видел, так как должен бы знать, что текущая спецификация шарпа имеет версию 1.2.

GZ> То что касается 2.0 умолчу, потому что знаю только по статьям. Вообще у кого больше по объему спецификация вопрос дурацкий.

Спецификация 2.0 распухла где-то процентов на 5-10. Но дело не в этом. Выучить ее на изусть очень непросто. Но учить ее на изусть смысла особого не имеет. В Шарпе настолько мало противоречий и алогизмов, что достаточно понимать его концепции.

GZ>С# за счет отсутсвия ссылок на память в managed коде действительно значительно облегчает ее понимание.

Понимание памяти?

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

VD>1. Довольно неразумно противопоставлять С++ дотнету, так как для дотнета без проблем можно писать на С++.
Без проблем? Впервые слышу. Сначало надо выучить что в данном managed С++ можно делать и что нельзя, научиться вставлять __gc и еще кучу параметров. Это уже не очень похоже на то что описывает Страуструп, это отдельный язык. И достаточно непохожий.
VD>2. В большинстве случае применение С++ мало чего дает. Хотя конечно всегда можно найти задачу где его использование будет более удобное.
Задачи сами тебя находят. Например, пришла к нам одна программа одного достаточно известного производителя на NET. Она хоть и конечно сервер, но требовать 1Г оперативной памяти в requariments для работы, это слишком.

VD>>>Ага. А еще легче тем кто на ВБ. Принципы то те же...
GZ>>Например, отсутсвие наследования. Для того чтобы сделать хороший дизайн, разработчику надо будет перестроить мышление.

VD>Причем тут это? Что по твоему в Шарпе мало похожих с ВБ чер?
Имеется, конечно, ввиду VB6. Собственно наплевать на то, какими словами ты пишешь for или if или даже наличие foreach. Когда-то я начинал с модульного программирования. Потом прочитал хорошую книгу и начал писать на OOP. Важно что изменились не только стиль программы, изменилось мышление. Потом, я начал писать для Windows 3.1. Прочел хорошую книгу, и сново изменилось мышление. Уже не было проблем с интерфейсом, зато появились чудеса квазимногозадачности. Дальше начал работать на Windows 95+NT, здесь перестройка ума, не была настолько существенной. Потом появился OLE со всеми причендалами, то же самое. Потом пересел на ASP. Ты знаешь как трудно привыкать к тому, что у тебя общение с пользователем всего лишь два стрима, response-request. Далее NET...
Мне плевать какими словами я запишу алгоритм, но мне не плевать на окружающую среду, если от этого зависит архитектура и дизайн, именно от этого зависит какой будет алгоритм.
В данном случае, есть маленькое изменение, которое затрагивает дизайн, и соответсвенно требует переосмысления инструментов, которыми ты пользуешься. Одно это маленькое (в кавычках) изменение открывает широкие горизонты по сравнению с VB6.

....skip
VD>Понятия Binding ни в языках дотнета, ни в CLR нет. Это идиома высокоуровневых библиотек. Не мешай мух с котлетами.
...skip

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

VD>И какая Платформа у С++ или Дельфи? Блин, оба языка без проблем используются для создания менеджед-кода. Дельфи так вообще даже серьезных изменений не претерпела, так как концептуально очень близка.
При C++ я уже написал свое мнение. Что касается Delphi, кому надо, пускай упражняются, но легкого переноса кода не будет, и следовательно, он мне в таком виде не интересен (если спросите что там изменилось, не отвечу. Мне это неинтересно. Я не слышал мнений программировать под NET для Delphi круче чем на VS+С#. Так что не вижу смысла).

VD>В общем, не нужно выдумывать сказок. Шарп — это сборная солянка со всех императивный языков существовавших до этого. Больше всего Шарп перенял из Явы и ВБ. Но это и это утверждение спорно. Дотнет является рантаймом для Шарпа. Потенциально шарп без проблем можно реализовать и на другом рантайме. Просто это мало кому нужно.

GZ>>Что касается С# 1.0, то не согласен.

VD>И давно ты читал спецификацию? Хотя судя по всему ты ее в глаза не видел, так как должен бы знать, что текущая спецификация шарпа имеет версию 1.2.
Давно, читал, в 2001 году. Ну извините, перечитать как-то не удается, приходится работать, зарабатывать хлеб насущный в том числе и на C#. Но как только, так сразу .

GZ>> То что касается 2.0 умолчу, потому что знаю только по статьям. Вообще у кого больше по объему спецификация вопрос дурацкий.

VD>Спецификация 2.0 распухла где-то процентов на 5-10. Но дело не в этом. Выучить ее на изусть очень непросто. Но учить ее на изусть смысла особого не имеет. В Шарпе настолько мало противоречий и алогизмов, что достаточно понимать его концепции.
Поскольку моей единственной информацией была именно ваша статья, поверю. Однако как сильно воздействуют эти изменения. Приведу пример из практики. Делалась программа на С++, использовался ATL, STL. Один программер попросил совета. Не помню в чем была ситуация, но решалась она красиво с помощью создания template. Программер, который писал на ATL, STL, был весьма хороший человек и коллега, как оказалось не умел этого делать. Через некоторое время, то же самое произошло с другим программером, в той же группе. Достаточно поучительный для меня случай был. Каким параметром это измерить?


GZ>>С# за счет отсутсвия ссылок на память в managed коде действительно значительно облегчает ее понимание.

VD>Понимание памяти?
Ну "его", смысл то понятен.

С уважением, Gleb.

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

GZ>Задачи сами тебя находят. Например, пришла к нам одна программа одного достаточно известного производителя на NET. Она хоть и конечно сервер, но требовать 1Г оперативной памяти в requariments для работы, это слишком.

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

GZ>Имеется, конечно, ввиду VB6. Собственно наплевать на то, какими словами ты пишешь for или if или даже наличие foreach. Когда-то я начинал с модульного программирования. Потом прочитал хорошую книгу и начал писать на OOP. Важно что изменились не только стиль программы, изменилось мышление.
GZ> Потом, я начал писать для Windows 3.1. Прочел хорошую книгу, и сново изменилось мышление.

А у меня все с точностью на оборот. Я сначала начал писать в ОО-стиле на С и потом я нашел С++ который позволял мне присать в этом стиле более просто. Потом я начал писать на С++ в компонетном стиле и использовать разные идиомы вроде ссылок на методы экземпляра. Потом я нашел Шарп который позволил мне делать все тоже самое намного проще и изящьнее.

GZ> Уже не было проблем с интерфейсом, зато появились чудеса квазимногозадачности. Дальше начал работать на Windows 95+NT, здесь перестройка ума, не была настолько существенной.

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

GZ> Потом появился OLE со всеми причендалами, то же самое.

И опять же. Оле (вренее КОМ) для меня стало методом позволяющим добавить компонентность в мои программы.

GZ> Потом пересел на ASP. Ты знаешь как трудно привыкать к тому, что у тебя общение с пользователем всего лишь два стрима, response-request. Далее NET...

Нет. Незнаю. АСП для меня выглядело как решение на базе КОМ и КОМ-скриптов.

GZ>Мне плевать какими словами я запишу алгоритм, но мне не плевать на окружающую среду, если от этого зависит архитектура и дизайн, именно от этого зависит какой будет алгоритм.
GZ>В данном случае, есть маленькое изменение, которое затрагивает дизайн, и соответсвенно требует переосмысления инструментов, которыми ты пользуешься. Одно это маленькое (в кавычках) изменение открывает широкие горизонты по сравнению с VB6.

А для меня все это выглядит как обычное итеративное развитие. Просто всзяли из ВБ все лучшее. Выкинули худшее и вуаля.

GZ>Все эту шнягу, я написал чтобы показать, что окружение первично, а не язык. Нафиг нужен CRL без высокоуровневых библиотек. Запишем высокоуровневые библиотеку как часть платформы, или окружения, как вам будет угодно. Все таки поставка, одна.

Вот опять смешал катлеты с мухами. Язык есть язык. ЦЛР есть ЦЛР. А библиотеки (не поверишь) есть библиотеки. В стандарт шарпа входит описание минимума библиотек без которых язык не мыслим. Но остальные — это средство поддржки программирования для кокретных задач (АСП, Виндовс ГУИ и т.п.) и для изучения программирования, а точнее для правильного понимания, что такое программирование все они ненужны. Ну, ненужно АСП.НЭТ для того чтобы научиться программировать. А вот язык нужен.

GZ>При C++ я уже написал свое мнение. Что касается Delphi, кому надо, пускай упражняются, но легкого переноса кода не будет,

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

GZ> и следовательно, он мне в таком виде не интересен (если спросите что там изменилось, не отвечу. Мне это неинтересно. Я не слышал мнений программировать под NET для Delphi круче чем на VS+С#. Так что не вижу смысла).

Дык сделай поиск по сайту и увидишь и такие.

GZ>Давно, читал, в 2001 году.

Т.е. до того как была выпущена первая версия дотнета, и соотвествено, спецификация шарпа?

GZ> Ну извините, перечитать как-то не удается, приходится работать, зарабатывать хлеб насущный в том числе и на C#. Но как только, так сразу .

Кстати, очень советую. Написан текст очень доходчиво и это занятие дает очень много с точки зрения понимания концепции языка.

GZ>Поскольку моей единственной информацией была именно ваша статья, поверю.

Давай лучше на ты. А то тут Вы начинают коворить при переходе на личности.

GZ> Однако как сильно воздействуют эти изменения. Приведу пример из практики. Делалась программа на С++, использовался ATL, STL. Один программер попросил совета. Не помню в чем была ситуация, но решалась она красиво с помощью создания template. Программер, который писал на ATL, STL, был весьма хороший человек и коллега, как оказалось не умел этого делать. Через некоторое время, то же самое произошло с другим программером, в той же группе. Достаточно поучительный для меня случай был. Каким параметром это измерить?

Сложностью изучения и применения технологии. Шаблоны в С++ стали слишком важной частью языка. Ими уже не решают проблемы дженерик-прграммирования, а натуральным образом модифицируют язык. Такие повороты не для каждого проходят гладко. Александреску сорвал крышу не одного программиста. АТЛ и СТЛ по сравнению с Локи и Бустом все же очень простые библиотеки. Хотя лично мне многое из АТЛ в свое время нравилось.

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

AVK>Это свидетельство не сложности, а запутанности и неоднозначности. Неинтуитивности, если хочешь.

Стоп. Изначатьно была фраза Влада:

А спецификация то у Шарпа посложнее чем у С++.

Я с ней не согласлся и привел очень сложные вещи из С++, описанные в его спецификации. Ничего подобного в С# нет. На фоне этих "штучек" C# кажется детской песенкой. О запутанности и неинтуитивности речи не шло.

Пример: в С# отсутствует частичная специализация шаблонов, и как следствие в его спецификации нет нетривиального алгоритма поиска наиболее специализированного шаблона. Стал он от этого проще? Да. Но его простота достигнута в ущерб функциональности.

GA>> И получается, что я своим кодом (кровью и потом ) кормлю потенциальную армию халявщиков? Кроме того, это сейчас обфускаторы выдают нечто нечитаемое... А потом энтузиасты "утирательства носа мелкософту" напишут тулзы, позволяющие ускорить разбор кода — закономерности всякие откопают, связи будут наглядно показывать и тэ пэ.

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

Все-таки используют. Не помню точно, но сборки толи Windows SharePoint Services, толи Microsoft SQL Server Reporting Services обфусцированы.

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

MN>>DataRow хранят элементы в виде object;
AVK>DataRow вобще ничего, кроме ссылки на DataColumn не хранит.

Это деталь реализации. В Mono, например, хранит.

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

AA>Все-таки используют. Не помню точно, но сборки толи Windows SharePoint Services, толи Microsoft SQL Server Reporting Services обфусцированы.

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

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

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

GZ>>Задачи сами тебя находят. Например, пришла к нам одна программа одного достаточно известного производителя на NET. Она хоть и конечно сервер, но требовать 1Г оперативной памяти в requariments для работы, это слишком.

VD>Весомый аргумет при выборе языка обучения. Да и гиг на сенодня серьезная пробелма.
Дело в том, что у нас та же функциональность написанная на С++, требует намного меньше ресурсов. Зачем им требуется 1Г для меня загадка. Есть только предположения, что это связано с особенностями ADO.NET. Ситуация описана в контексте вопроса о превликательности продукта.

GZ>>Имеется, конечно, ввиду VB6. Собственно наплевать на то, какими словами ты пишешь for или if или даже наличие foreach. Когда-то я начинал с модульного программирования. Потом прочитал хорошую книгу и начал писать на OOP. Важно что изменились не только стиль программы, изменилось мышление.
GZ>> Потом, я начал писать для Windows 3.1. Прочел хорошую книгу, и сново изменилось мышление.

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

GZ>> Уже не было проблем с интерфейсом, зато появились чудеса квазимногозадачности. Дальше начал работать на Windows 95+NT, здесь перестройка ума, не была настолько существенной.

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

GZ>> Потом появился OLE со всеми причендалами, то же самое.

VD>И опять же. Оле (вренее КОМ) для меня стало методом позволяющим добавить компонентность в мои программы.

GZ>> Потом пересел на ASP. Ты знаешь как трудно привыкать к тому, что у тебя общение с пользователем всего лишь два стрима, response-request. Далее NET...

VD>Нет. Незнаю. АСП для меня выглядело как решение на базе КОМ и КОМ-скриптов.

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

GZ>>Все эту шнягу, я написал чтобы показать, что окружение первично, а не язык. Нафиг нужен CRL без высокоуровневых библиотек. Запишем высокоуровневые библиотеку как часть платформы, или окружения, как вам будет угодно. Все таки поставка, одна.

VD>Вот опять смешал катлеты с мухами. Язык есть язык. ЦЛР есть ЦЛР. А библиотеки (не поверишь) есть библиотеки. В стандарт шарпа входит описание минимума библиотек без которых язык не мыслим. Но остальные — это средство поддржки программирования для кокретных задач (АСП, Виндовс ГУИ и т.п.) и для изучения программирования, а точнее для правильного понимания, что такое программирование все они ненужны. Ну, ненужно АСП.НЭТ для того чтобы научиться программировать. А вот язык нужен.
Занятно. В данном контексте я с вами соглашусь. Хотя существует 2 вопроса. А что вы подразумеваете под термином научиться программировать? Лично я до сих пор учусь программировать. Всегда найдется интересная сторона на вроде бы уже известных методах. Ну а во вторых, человек учится программировать для решения определенных задач. И в современном мире, разработчики уже разбиты по специализациям (например ASP.NET и(или) WinGUI и(или) ...). Если он знает как построить цикл или как наследуются классы (и даже умеет это делать правильно и по делу), никому он как просто программист не интерен.

GZ>>При C++ я уже написал свое мнение. Что касается Delphi, кому надо, пускай упражняются, но легкого переноса кода не будет,

VD>Ага. Вот только есть. Программы не использующие явной работы с указателями (а это редкость для Дельфи) и компонетнов третьих фирм, без проблем перекомпилируются в менеджед-приложения.
Сразу же скажу, на промышленных системах не редкость, и стандартные компоненты (что в Delphi что в NET) достаточно бедны. Их или сами дописывают, или закупают у третьих фирм. В случае делфы, когда те же компоненты несовместимы даже на двух соседних (не NET) версиях, вообще случай криминальный.

GZ>>Давно, читал, в 2001 году.

VD>Т.е. до того как была выпущена первая версия дотнета, и соотвествено, спецификация шарпа?
Возможно на бete или SDK. Уже не помню. Помню только что на каждом перекрестке утверждалось, что NET решит все ваши проблемы (притом людьми которые его и в глаза не видели). С тех пор ничего не изменилось (надеюсь что ты не из этого числа). Только спецификация практически не изменилась.

GZ>> Ну извините, перечитать как-то не удается, приходится работать, зарабатывать хлеб насущный в том числе и на C#. Но как только, так сразу .

VD>Кстати, очень советую. Написан текст очень доходчиво и это занятие дает очень много с точки зрения понимания концепции языка.
Занятно, открыл MSDN, Visual C# Language->C# Language Tour. В глаза бросается статья "Comparison Between C++ and C#".

GZ>>Поскольку моей единственной информацией была именно ваша статья, поверю.

VD>Давай лучше на ты. А то тут Вы начинают коворить при переходе на личности.

GZ>> Однако как сильно воздействуют эти изменения. Приведу пример из практики. Делалась программа на С++, использовался ATL, STL. Один программер попросил совета. Не помню в чем была ситуация, но решалась она красиво с помощью создания template. Программер, который писал на ATL, STL, был весьма хороший человек и коллега, как оказалось не умел этого делать. Через некоторое время, то же самое произошло с другим программером, в той же группе. Достаточно поучительный для меня случай был. Каким параметром это измерить?

VD>Сложностью изучения и применения технологии. Шаблоны в С++ стали слишком важной частью языка. Ими уже не решают проблемы дженерик-прграммирования, а натуральным образом модифицируют язык. Такие повороты не для каждого проходят гладко. Александреску сорвал крышу не одного программиста. АТЛ и СТЛ по сравнению с Локи и Бустом все же очень простые библиотеки. Хотя лично мне многое из АТЛ в свое время нравилось.
Согласен

С уважением, Gleb.

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

GZ>Дело в том, что у нас та же функциональность написанная на С++, требует намного меньше ресурсов. Зачем им требуется 1Г для меня загадка. Есть только предположения, что это связано с особенностями ADO.NET. Ситуация описана в контексте вопроса о превликательности продукта.

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

Однако я предпочту гиг в системных требоаваниях чем сервер написанный на С++. Намного проще купить пору лишних гиг оперативки, чем думать об очередном трудно уловимом баге. Уж больно тяжело отладить объемистый С++-код (особенно если писали его не супер опытные товарищи, коих в принципе мало).

GZ>Называется, померялись животами.

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

GZ> Кстати, я никогда не отвергал наследование в рамках компонента, точно так же делал компоненты еще до того как оно проявилось у меня на горизонте. Когда проявилось чисто компонентное программирование (в моем случае это был COM) это была всего лишь констатация некоторого факта.

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

GZ>А что вы

Давай на ты. А то "вы" тут не очень принято. Да и "вы" с маленькой буквы совсем некрасиво. Меня же не двое?

GZ> подразумеваете под термином научиться программировать?

Хороший вопрос.

GZ> Лично я до сих пор учусь программировать. Всегда найдется интересная сторона на вроде бы уже известных методах. Ну а во вторых, человек учится программировать для решения определенных задач. И в современном мире, разработчики уже разбиты по специализациям (например ASP.NET и(или) WinGUI и(или) ...). Если он знает как построить цикл или как наследуются классы (и даже умеет это делать правильно и по делу), никому он как просто программист не интерен.

Ну, это уже не учеба программировать, а скорее самосовершенствование. Хотя с некоторой натяжкой можно сказать и так.

GZ>Сразу же скажу, на промышленных системах не редкость, и стандартные компоненты (что в Delphi что в NET) достаточно бедны. Их или сами дописывают, или закупают у третьих фирм. В случае делфы, когда те же компоненты несовместимы даже на двух соседних (не NET) версиях, вообще случай криминальный.

И тем не менее компоненты тут не причем. Совместимость есть и она очень высокая.

GZ>Возможно на бete или SDK.

СДК возможно. Но в нем нет полной спецификации. Специяикация вышла чуть позже.

GZ>Занятно, открыл MSDN, Visual C# Language->C# Language Tour. В глаза бросается статья "Comparison Between C++ and C#".

МСДН это не то. Полноценную спецификацию берут здесь: http://msdn.microsoft.com/vcsharp/team/language/default.aspx