Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте Anton V. Kolotaev, Вы писали:
AVK>>Меня интересует вопрос, как следует переводить термины weaving code и separation of concerns. AVK>>Для weaving code мне кажется улачгым переводом модет послужить сотканный, сплетенный или переплетенный код. Сответственно weaving как процесс можно перевести как "сплетение".
AVK>Сращивание
Во! Кажется нашёл — "слияние".
Правда, вот что делать с SoC пока толком не представляю. По идее, если буквально перевести, то получится "Разделение озабоченностей". Наверное, что-то вроде "Разделения соглашений". Вобщем, надо думать...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>Чего за прикол? Все смайлики покоцались. AVK>Смайлики были у слова провокатор и про определение компилятора.
AVK>еще раз попробую AVK>
Да ладно, я не обиделся
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Коллеги, я почитал ваши мнения (Vlad2, IT, old->*Plutonia_Experiment() ), добавил своих измышлизмов и кое-чего, почерпнутого из сайтов. Теперь попробую обоснованно вывести определения.
[...]
AVK>Провокатор?
Да нет, просто на самом деле, жду формулировок от оппонентов. Поскольку они молчат, то решил предложить свои формулировки.
ГВ>>"Блочность" сборки подразумевает, прежде всего, наличие каких-либо соглашений "о контактах и сигналах". Применительно к ПО — это соглашения, обеспечивающие бинарную совместимость "блоков" (применительно к ПО они называются модулями) или наличие инфраструктуры, осуществляющей согласование модулей при отсутствии их бинарной совместимости.
AVK>Почему именно бинарной? Корба или веб-сервисы как то без обходиться. И никаких согласователей там не наблюдается.
Собственно говря, поскольку в неё всё в конечном итоге упирается. Самое "прозрачное" совмещение компонентов возможно при их бинарной совместимости. Приняв такую модель совместимости за "предел совершенства", я и сформулировал тезис. На мой взгляд, он достаточно правомерен.
ГВ>>Третий аспект — любой компонент может быть заменён своим функциональным аналогом, возможно, написанным на другом языке, что не должно повлечь за собой необходимости замены других компонентов системы.
AVK>Это совершенно не обязательно. Или ты Дельфи или джаве отказываешь в компонентности?
Ни в коем случае. Я сказал — возможно.
ГВ>>В сухом остатке, получается, что компонентно-ориентированное программирование – это, прежде всего, подход, ориентированный на использование разных языков программирования, но ограниченный при этом одной-единственной компонентной инфраструктурой. Подход, в основном, упирает на независмый deployment компонентов.
AVK>Про языки см. выше.
Пожалуй, что ты прав. В определении акцент, вероятно, следует сделать на инфраструктурную составляющую.
VD>>> Атрибутное (декларативное) программирование — программирование где многие логические аспекты не прописываются в коде, а задаются в виде атрибутов. В Шарпе это выглядит так:
AVK>На определение не катит. Атрибуты тоже прописываются в коде. И еще — Атрибутное ... — ... ввиде атрибутов. Это как: AVK>Что такое компилятор? Эта такая программа которая компилирует. А что такое компилировать? Это то что делает компилятор. AVK>Есть нормальное определение в документации — атрибуты это метаданные, структура которых определяется пользователем.
ГВ>>OK. Значит, атрибуты – суть данные, которые могут анализироваться какими-то внешними средствами, будь то компилятор, утилиты регистрации, браузеры (вероятно) всех мастей и т.п.
AVK>Прежде всего внутренними. Компилятор шарпа кстати тоже написан на шарпе и работает в CLR.
OK, сократим формулировку до: "... могут анализироваться какими-то средствами ...".Справедливости ради, стоило ввести понятие "внутреннего" и "внешнего" средства.
ГВ>>Атрибуты, вероятно, характеризуются именем, и типом значения.
AVK>Не так примитивно. Атрибуты это классы, экземпляры которых создает компилятор, когда встречает в исходном коде их использование. Соответственно атрибут может нести целую кучу значений и связанным с ними кодом.
В сущности — класс атрибута это и есть тип его значения.
ГВ>>SQL, Prolog – это тоже декларативные языки, подразумевающие наличие системы, обрабатывающей декларации. AVK>Пролог не декларативный, в отличие от SQL92. Это продукционный язык. Более известный аналог — язык шаблонов XSLT. Да и sql декларативный только то что в стандарте. Реальные языки, вроде transact sql или pl/sql имеют как декларативную так и экзекутивную часть.
OK, возможно, пример не совсем удачен, хотя замечу, что Prolog нередко называют декларативным языком. Ну да не в примере дело в конце-концов.
ГВ>>Так что, важнейшая деталь, ИМХО, это система интерпретации семантики атрибутов. Внешние средства обязаны располагать информацией о семантике атрибутов, чтобы адекватно их использовать. Иначе, атрибуты – ноль без палочки, как и компоненты. Поэтому в определении я убрал слово "декларативное", оставив только "атрибутное".
AVK>Что ты понимаешь под семантикой атрибутов?
Смысловую нагрузку. Простейший пример — атрибут Guid(...) имеет вполне ясный смысл для компилятора IDL, или C#. Его семантика достаточно ясная — он определяет значение "глобально уникального идентификатора" класса.
ГВ>>Итак, сухой остаток – атрибутное программирование, суть программирование в терминах какой-либо инфраструктуры, которая располагает информацией об использовании атрибутов.
AVK>Это можно сказать про очень много видов программирования. Не в этом изюминка атрибутов. Атрибутное программирование это прежде всего программирование метаданных. Другой вид такого программированиия — часть Reflection.Emit, так которая не касается собственно IL опкодов.
Хм... Ну, вообще-то Reflection.Emit и есть та самая инфраструктура, которая интерпретирует атрибуты.
ГВ>>OK. На мой взгляд, твоё определение достаточно ясно выделяет главное – “подход”. Я покопался на aosd.net и пришёл к тому, что аспектное программирование (если точнее – то software design) можно в каком-то смысле назвать «гиперкомпонентным» программированием.
AVK>Непонятно.
Ну, может быть и не очень удачный термин. Эмоции, понимаешь. Собственно, на определение само по себе это не повлияло.
ГВ>>
ГВ>>Aspect-oriented programming addresses the problem that the implementation of some properties such as error handling and optimization tends to cross-cut the basic functionality.
AVK>Проблема разделения продукционного кода и обработки ошибок сродни мсовскому dll hell Столько уже для этого напредлагали, говоря что вот наконец решили, а потом опять. Те же исключения из той же оперы.
Ничего не поделаешь, поиск, сам понимаешь...
ГВ>>Компонентно-ориентированное программирование.
ГВ>>Подход к разработке, ориентированный на использование разных языков программирования,
AVK>Как я уже говорил — в корне неверно
OK, я согласен с твоим доводом. Компонентное программирование акцентировано на поддерживающей компоненты инфраструктуре. Многоязычие можно считать частным случаем развития инфраструктуры компонентного программирования.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте Геннадий Васильев, Вы писали:
ГВ>Собственно говря, поскольку в неё всё в конечном итоге упирается. Самое "прозрачное" совмещение компонентов возможно при их бинарной совместимости. Приняв такую модель совместимости за "предел совершенства", я и сформулировал тезис. На мой взгляд, он достаточно правомерен.
Не вижу никакой принципиальной разницы между бинарной и текстовой совместимостью.
AVK>>Не так примитивно. Атрибуты это классы, экземпляры которых создает компилятор, когда встречает в исходном коде их использование. Соответственно атрибут может нести целую кучу значений и связанным с ними кодом.
ГВ>В сущности — класс атрибута это и есть тип его значения.
Не стоит все же упрощать атрибут до именованного значения. К примеру в конструкторе атрибут может произвести какие то действия (при компиляции!). Какие то значения могут вычисляться (опять же — и при компиляции и при чтении), значения могут подгружаться из внешнего источника. Да при желании много чего можно наворотить вроде АОП для атрибутов. Все же называть полноценный класс парой имя-значение несколько некорректно.
ГВ>OK, возможно, пример не совсем удачен, хотя замечу, что Prolog нередко называют декларативным языком. Ну да не в примере дело в конце-концов.
Какой он нафик декларативный если в теле продукции совсем недекларативные конструкции. Он декларативный только на верхнем уровне — наборе продукций (правил), а точнее их условной части.
AVK>>Что ты понимаешь под семантикой атрибутов?
ГВ>Смысловую нагрузку. Простейший пример — атрибут Guid(...) имеет вполне ясный смысл для компилятора IDL, или C#. Его семантика достаточно ясная — он определяет значение "глобально уникального идентификатора" класса.
Атрибут в общем случае может не иметь семантики и сам по себе производить какие то действия. См. выше примеры.
ГВ>Хм... Ну, вообще-то Reflection.Emit и есть та самая инфраструктура, которая интерпретирует атрибуты.
Ничего подобного. Атрибуты это отдельно, может внутри они и через рефлекшен достаются, но генерационная часть точно не рефлекшена. В программе же интерпретацией занимается совершенно отдельный класс. Эмит же вобще ничего не интерпретирует, он занимается генерацией метаданных и кода. Вот та часть которая генерирует близка по духу к атрибутам.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте Геннадий Васильев, Вы писали:
ГВ>>Собственно говря, поскольку в неё всё в конечном итоге упирается. Самое "прозрачное" совмещение компонентов возможно при их бинарной совместимости. Приняв такую модель совместимости за "предел совершенства", я и сформулировал тезис. На мой взгляд, он достаточно правомерен.
AVK>Не вижу никакой принципиальной разницы между бинарной и текстовой совместимостью.
В каком-то смысле я тоже не вижу разницы. Вот потому я и выбрал термин "бинарная" как более общий. Здесь, ИМХО, правомерно утверждение, что "текстовая совместимость" — ипостась "бинарной совместимости". То есть, хорошо бы иметь бинарную, но за неимением такой возможности сойдёт и "текстовая". На самом деле, ИМХО, что бинарная, что текстовая совместимости — просто способы реализации инфраструктуры, обеспечивающей взаимодействие.
AVK>>>Не так примитивно. Атрибуты это классы, экземпляры которых создает компилятор, когда встречает в исходном коде их использование. Соответственно атрибут может нести целую кучу значений и связанным с ними кодом.
ГВ>>В сущности — класс атрибута это и есть тип его значения.
AVK>Не стоит все же упрощать атрибут до именованного значения. К примеру в конструкторе атрибут может произвести какие то действия (при компиляции!). Какие то значения могут вычисляться (опять же — и при компиляции и при чтении), значения могут подгружаться из внешнего источника. Да при желании много чего можно наворотить вроде АОП для атрибутов. Все же называть полноценный класс парой имя-значение несколько некорректно.
Сам по себе класс называть такой парой действительно некорректно, но атрибут по отношению к атрибутируемому классу (даже если этот атрибут сам по себе является классом) — это всё равно пара имя-значение. Значение может зависеть от разных факторов (например, состояния экземпляра, которому сопоставлен атрибут), оно может иметь какой-то непростой тип, вычисление значения может повлечь за собой ещё вагон других действий и т.п. Вобщем-то, вызов метода атрибута, это получение части его значения.
Хотя, знаешь, идея! Можно заменить определение "имя-значение" (кстати, я говорил о паре "имя-тип") фразой "сопутствующий объект, с которым могут взаимодействовать как объекты программы, так и внешние по отношению к программе средства (в частности — компилятор)".
ГВ>>OK, возможно, пример не совсем удачен, хотя замечу, что Prolog нередко называют декларативным языком. Ну да не в примере дело в конце-концов.
AVK>Какой он нафик декларативный если в теле продукции совсем недекларативные конструкции. Он декларативный только на верхнем уровне — наборе продукций (правил), а точнее их условной части.
OK, Prolog — не полностью декларативный язык. И давай завяжем с ним.
AVK> AVK>>>Что ты понимаешь под семантикой атрибутов?
ГВ>>Смысловую нагрузку. Простейший пример — атрибут Guid(...) имеет вполне ясный смысл для компилятора IDL, или C#. Его семантика достаточно ясная — он определяет значение "глобально уникального идентификатора" класса.
AVK>Атрибут в общем случае может не иметь семантики и сам по себе производить какие то действия. См. выше примеры.
Вот эти действия и есть его семантика.
ГВ>>Хм... Ну, вообще-то Reflection.Emit и есть та самая инфраструктура, которая интерпретирует атрибуты.
AVK>Ничего подобного. Атрибуты это отдельно, может внутри они и через рефлекшен достаются, но генерационная часть точно не рефлекшена. В программе же интерпретацией занимается совершенно отдельный класс. Эмит же вобще ничего не интерпретирует, он занимается генерацией метаданных и кода. Вот та часть которая генерирует близка по духу к атрибутам.
Хорошо, назовём .NET инфраструктурой, а Emit — её частью. По-моему — справделиво.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте Sergey, Вы писали:
S>>Чтоб не флеймить зря, покажи, как на C# реализуется эта самая парадигма — тогда можно будет предметно обсудить, чего в С++ не хватает.
VD>Вот пример из соседнего формума: VD>
Пример поскипан.
VD>
VD>Это COM+-объект созданный на C#. Без применения атрибутов мне прилось бы создать отдельный idl-файл с описанием интерфейсов, ко-классов и библиотеки типов. Это — раз. Ну и при регистрации пришлось бы задать все параметры вручную или написать нехилый скрипт для их задания. Тут же я обхожусь заданием атрибутов.
Этот пример говорит только о том, что модель COM (а именно, расширенная динамическая информация о типах в стиле IDispatch) плохо стыкуется со статически типизированным C++. Никакой новой парадигмой тут и не пахнет. Грубо говоря, если мне в плюсовом коде у класса A нужен атрибут GUID, я пишу:
class ClassWithoutGUID : public ClassWithGUIDBase
{
public:
virtual bool HasGUID() const
{ return false; }
virtual void GetGUID(GUID &id) const
{ throw std::runtime_error("Да нет у меня гуида"); }
};
class A : ClassWithGUID
{
public:
A() : ClassWithGUID(&some_id)
{
...
}
}
Те же атрибуты, только типизация — статическая.
VD>Вообще атрибуты — это методанные которые могут анализироваться неким кодом (от компилятора, до утилит регисрации) и на базе них можно принимать те или иные решиния.
Ну, метаданными в C++ является только информация о типах. Компилятор эту информацию вполне может анализировать, сторонние утилиты — нет, но и необходимости в этом почти не возникает. Дело в том, что в примере, который ты привел, все атрибуты используются только для поддержки взаимодуйствия со средой выполнения и в случае C++ вполне могут быть заменены на все то же наследование библиотечных классов.
VD>>>Вот если бы С++ развивался, то и замену ему искать не пришлось бы.
S>>Ну давай теперь флеймить на тему, является ли Java заменой C++ или дополнением и зачем MS выпустила .Net Сразу скажу, я не считаю, что причинами появления Java и .Net является несовершенство С++. Другие были причины, совсем другие.
VD>А я считаю. Мне тоже многое в С++ нарвится больше. Но этот язык уже прогнулся от своей сложности. Я конечно понимаю, что шалоны на столько мощная вещь что ими можно закрыть почти все ошибки в проектировании языка, но это перекладывание обязанностей с разработчиков языка на прикладников. И к тому же в главной области — компонентном программировании со стороны С++ нет даже малейших потугов.
Неа. Это перекладывание обязанностей на разработчиков библиотек Я вот, например, не знаю в деталях, как boost::bind внутри устроен, но успешно его использую, поскольку эта функция куда удобней, чем вполне прозрачные, но убогие stl'ные bind1st и bind2nd. А компонентное программирование — COM меня почти устраивал, вот только библиотеки (да и мокрософтовский подход вообще) к нему уж больно убогие. Впрочем, учитывая ужасную поддержку шаблонов в основном "COM'овском" компиляторе и медленное развитие приемов метапрограммирования в С++ (ну тут уже не MS виновата), другого ожидать и не приходится.
VD>>>Например? Множественное наследование спокойно на шаблонах обходится. Больше я ничего не заметил.
S>>Ключевое слово — обходится. На ассемблере вообще все обходится, только вот не человеческое это дело, на ассемблере большие программы писать... Кстати, покажи, как именно обходится — че то в удобство такого метода не очень верится.
VD>И причем тут ассемблер? Демогогия одно слово.
Это не демагогия, а гипербола. Демагогия — это когда кто-то заявляет, что "множественное наследование спокойно на шаблонах обходится", а потом, когда его попросили пояснить, что он под этим понимает, делает вид, что он про это не говорил или его ни о чем не спрашивали.
VD>Множественное наследование хорошо только для одного дела — подключение готовых реализаций.
Именно. Оно для того и придумывалось. Конкретное средство для решения конкретной проблемы. Его отсутствие в C# — шаг назад, к C и ассемблеру
VD>В остальном от него только одни проблемы.
Какие именно? Проблемы я пока видел только от "бриллиантового" множественного наследования. Вот его вполне можно и из С++ исключить, хотя и для него есть вполне оправданная область применения.
VD>Я согласен, что ATL демонстрирует эффективность этго подхода.
ATL, IMHO, демонстрирует, что в команде его разработчиков максимум один человек более-менее проникся C++ и ООП, а остальные там махровые сишники.
VD>Но ведь для подключения реализаций можно пользоваться и более простыми методами.
Ну а я не считаю агрегацию более простым методом, чем множественное наследование.
VD>Мне, например, кажется что введение в язык агрегации (подключения внешних классов в качестве реализации интерфейсов) было решило бы эту проблему. Ну да об этом мы уже много дискутировали.
Поддержка агрегации компилятором (языком) может, и не помешала бы. Однако нафига иметь в языке два средства, делающие одно и то же?
VD>В С++ главная проблема — это непомерная сложность. Да на нем можно все. Но какй цено! В .NET же я могу писть основной костяк программы на простом и удобном языке, а когда нужно использовать С++. Правд практика показывает, что обычно это использование ограничивается созданием оберток над разыми нэйтив-АПИ.
Мало-мальски сложные алгоритмы на шарпе кодировать ну очень не удобно. Хотя может, я еще просто не научился. Ну и с шаблонами, даже самыми примитивными, полегче будет.
S>>А не хватает, например, нормальных деструкторов,
VD>Мне в первое время тоже не хватало. Но во времением понимаешь, что это вобщем-то просто привычка. Хотя для вэлью-типов можно было бы добавить.
Это вопрос удобства, а не просто привычка. Ручная очистка ресурсов там, где раньше была автоматическая — шаг назад.
S>>argument-dependent name lookup,
VD>Это я вообще не понял, что такое?
В MSDN загляни, оно там описано.
S>> директивы using внутри функций
VD>Никогда не испытывал необходимости.
Когда один класс должен использовать одноименные классы из разных неймспейсов (особенно если внутри одной функции), просто необходимая вещь. Без него — только полная квалификация имен.
VD>И не помню чтобы такое было в С++.
Даже в VC 6.0 есть. using действует до конца области видимости — если оно не так, то это ошибак в компиляторе.
VD>Уж лучще добавить With как в VB. Чтобы к членам объектов можно было обращаться через одну точку.
Ну это дело вкуса. Хотя как быть с операторами?
S>> — эти козлы ничего умнее, чем считать ее там за using statement не придумали.
VD>using — это как раз замена тем самым деструкторам. Блок контролирующий освобождение ресурсов.
Вот-вот, совершенно другая вещь, а назвали так же (и тем самым запретили тот, другой using). Уроды.
S>>Привязки параметров в делегатах не хватает, причем, в отличие от C++, руками ее не напишешь.
VD>Опять же не понял о чем идет речь? Уж делегаты то в нэте куда лучше уродливых указателей на методы класса в С++. Локанично и эффективно.
Имеются в виду Loki::Functor, Loki::BindFirst или все тот же boost::bind. И что такого уродливого в указателях на методы класса? Совершенно логичная штука. Не, я не против, что бы в язык добавили чего-нибудь типа closure, но и без них не плохо.
S>>Возможности написать ручной распределитель памяти для конкретного класса не хватает.
VD>Опять же на С++ это обхдится. Да и на Шарпе в ансэйф-режиме тоже. Но практика показывает, что в этом просто нет нужды.
Это кому как. Если я знаю, что сейчас в вектор или стрим буду много-много мегабайт запихивать, а потом все освобожу одним куском, то ручной распределитель памяти дает ускорение иногда аж в 500-1000 раз (C++ код, 30 мег данных пишутся в стрим в памяти).
S>>Внутренней непротиворечивости, в конце концов, не хватает — взять хотя бы исключения в деструкторах или в finally.
VD>Да вызывай ты исключения в finally сколько влезит. Просто после этого все проблемы будут твои.
А все проблемы и так всегда мои, если программу пишу я, а не MS Мне надо что-то вроде C++'ного uncaught_exception в деструкторе и нормальные деструкторы вместо finally, который все ООП рушит нафиг.
S>>В общем, чем дальше в лес, тем чудесатее и чудесатее. Сырой язык.
VD>Ничего там сырого нет. Ты назвал все спорные места. Других нет.
Хе-хе, вон в C++ спорные места до сих пор находят, а ты говоришь, что я, практически незнакомый с C#, за один раз все спорные места в нем нашел
VD>Но и те что есть сделаны так не по недомыслию, а совершенно осознанно. Они как раз добивались той самой простоты программирования, которой как раз так нехватает в С++.
И которая хуже воровства Ну не делаются сложные вещи простыми инструментами, и все тут. Вернее, делаются, он это сложнее, чем делать их более сложным инструментом.
VD>В нэте шаблоны называются дженирик, т.е. подрозумевается что их раскрытие будет производиться не компилятором, а CLR.
В C++ использование шаблонов в некоторых случаях тоже называется дженирик программинг, но подрозумевается что их раскрытие производится компилятором. Что-то не так с терминологией.
VD>Насклоько они будут мощны я пока не знаю. Но даже если они будут на уровне VC6, меня это устроит.
А меня, к сожалению, нет.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
ГВ>Атрибутное программирование.
ГВ>Атрибутное программирование – описание свойств в терминах какой-либо инфраструктуры (атрибутах), располагающей информацией об использовании атрибутов.
Атрибутное программирование – это обрамление класса другими классами (без иерархии ИЛИ не составляющие с исходным классом никакой иерархии).
Я имею в виду, что никакой атрибут не может быть получен из иерархии объекта, а только через "левый" путь: через метаданные и т.п.
Здравствуйте Aquila, Вы писали:
A>i) Производительность Win2k (а тем паче WinXP) на моем компьютере (Duron 800/384) меня не устраивает.
У меня сервер на PII 233 прилично работае... К тому же ХаРэ все одно на твоей машине будет шустрее чем 98-ые.
A>ii) Многие программы, к которым я привык и от чьего использования отказываться не намерен, не работают или работают неверно.
Например? У меня нормально работают 16-битная бухгалтения и Dave (старая досовская игрушка от id).
A>Не забудьте встроить в Янус упаковку почты .
Здравствуйте Aquila, Вы писали:
A>В свое время у меня был 486/24, на котором я гонял CBuilder 4. Меня тоже устраивало "время отклика". Ну и что? Тебя устраивало, а я тормоза не люблю. Был бы компьютер побыстрее, поставил бы Win2k, но не вижу никакого смысла , чтобы тратить деньги на апгрейд только ради этого.
Ты бы поставил, а потом трепался бы. На 300-х мегах W2k за всегда шустрее 98-х будет. Она эту память использовать умеет.
A>Зачем привыкать к тормозам? К тому же второй пункт (о том, что не работают нужные мне программы) играет не меньшую роль. Конечно, можно попробовать найти им замену, но... зачем? Зачем напрягаться, когда и так все работает, как нужно? Я люблю научнотехнический прогресс, но не за счет моих денег и времени и не вижу никакого смысла ставить новые версии ОС, если они не могут обеспечить того, что есть у меня уже сейчас .
Их твоих слов видно только одно. W2k ты видил только у других. А ХаРэ вообще не видил.
Здравствуйте, Vi2, Вы писали:
Vi2>Здравствуйте, Геннадий Васильев, Вы писали:
Vi2>
ГВ>>Атрибутное программирование.
ГВ>>Атрибутное программирование – описание свойств в терминах какой-либо инфраструктуры (атрибутах), располагающей информацией об использовании атрибутов.
Vi2>Атрибутное программирование – это обрамление класса другими классами (без иерархии ИЛИ не составляющие с исходным классом никакой иерархии).
Ну, вероятно, не классами, а всё-таки — экземплярами.
Vi2>Я имею в виду, что никакой атрибут не может быть получен из иерархии объекта, а только через "левый" путь: через метаданные и т.п.
В смысле — приведением типа объекта к типу атрибута? Если так, то согласен. Как раз "левый" путь — это и есть обработка информации о типе.
OK, Thanx
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте Геннадий Васильев, Вы писали:
Vi2>>Атрибутное программирование – это обрамление класса другими классами (без иерархии ИЛИ не составляющие с исходным классом никакой иерархии).
ГВ>Ну, вероятно, не классами, а всё-таки — экземплярами.
Здравствуйте PSP, Вы писали:
PSP>Я принципиально против таких рассуждений. Если вижуал одинаковый и там и там, нахрен мне глюки иметь. А совместимость всё равно идёт снизу вверх, если я прилаги писать буду под NT4, то под 2k они тем более работать будут..
Ты под "вижуалом" VC6 имееш в иду? Ну у меня под W2k это дело уже два года работает и ничего. Сейчас вот под ХаРэ работает. К тому же студия тоже новая появилась. Та так просто на 98-е уже не рассчитана.
Здравствуйте Sergey, Вы писали:
S>Этот пример говорит только о том, что модель COM (а именно, расширенная динамическая информация о типах в стиле IDispatch) плохо стыкуется со статически типизированным C++. Никакой новой парадигмой тут и не пахнет.
Конечно не пахнет! Еще если хочешь чтобы чай стал сладким без сахара, говори себе "сахар, сахар, сахр, ...) и сразу станет легче.
S>Ну, метаданными в C++ является только информация о типах. Компилятор эту информацию вполне может анализировать, сторонние утилиты — нет, но и необходимости в этом почти не возникает.
Да это тоже полезно. Говориш себе "мне это не нужно, меня это не интересует" и сразу становится легче. Аутотренинг — вещь полезная!
S>Дело в том, что в примере, который ты привел, все атрибуты используются только для поддержки взаимодуйствия со средой выполнения и в случае C++ вполне могут быть заменены на все то же наследование библиотечных классов.
В случае С++ они могут быть заменены на килобайт скриптов. Больше ни на что. А про "поддержку взаимодуйствия со средой выполнения" это ты правильно подметил. В С++ этот намного лучше и удонее. Главное говорить сбе "вахар...).
S>Это не демагогия, а гипербола. Демагогия — это когда кто-то заявляет, что "множественное наследование спокойно на шаблонах обходится", а потом, когда его попросили пояснить, что он под этим понимает, делает вид, что он про это не говорил или его ни о чем не спрашивали.
Кто что делает? Ты перечитай еще разок мои постинги. А шаблоны действительно позволяют эмулировать множественное наследование.
class C : A< B< C > {};
Ну а демагогия — это 1. Основанное на намеренном извращении фактов воздействие на чувства, инстинкты малосознательной части масс. 2. Рассуждения или требования, основанные на грубо одностороннем истолковании чего-н.
VD>>Множественное наследование хорошо только для одного дела — подключение готовых реализаций.
S>Именно. Оно для того и придумывалось. Конкретное средство для решения конкретной проблемы. Его отсутствие в C# — шаг назад, к C и ассемблеру
В С а тем более асм-е наследования неблыло вообще. Так что не надо. К тому же ты прекрасно знаешь все проблемы множественного наледования.
S>Какие именно? Проблемы я пока видел только от "бриллиантового" множественного наследования. Вот его вполне можно и из С++ исключить, хотя и для него есть вполне оправданная область применения.
Дублирование наследников, проблемы при приведении типов, молопонятные сообщения компиляторов и еще много чего. А облость применения можно найти для любых извращений.
S>ATL, IMHO, демонстрирует, что в команде его разработчиков максимум один человек более-менее проникся C++ и ООП, а остальные там махровые сишники.
Ага. Я бы сказал бы ламеры. И почему только эти неотесанные программисты так его любят? Если серьезно, то вообще не ясно почему ATL нужно оценивать с точки зрения ОО (хотя и с этой точки зрения там все впорядке).
S>Ну а я не считаю агрегацию более простым методом, чем множественное наследование.
От нее нет таких проблем как от наследования. К тому же она может производиться в рантайме.
S>Поддержка агрегации компилятором (языком) может, и не помешала бы. Однако нафига иметь в языке два средства, делающие одно и то же?
Дык это не одно и тоже. У тебя получется с одной стороны дерево типов. С другой решается проблема повторного использования кода.
S>Мало-мальски сложные алгоритмы на шарпе кодировать ну очень не удобно. Хотя может, я еще просто не научился. Ну и с шаблонами, даже самыми примитивными, полегче будет.
Кодировать то на Шарпе удобно. Если конечно задача может быть реализована для разных типов, то шаблоны бы не помешали. И в общем то и добавят в следующей версии. Жаль что этого еще долго ждать.
S>Это вопрос удобства, а не просто привычка. Ручная очистка ресурсов там, где раньше была автоматическая — шаг назад.
Для стековых переменных есть using. Так что жтого даже не замечаешь. Ну а для не стековых при наличии GC детерминированную финализацию обеспечить невозможно. Так что это компромис. Но я лично на своей шкуре прочуствовал насколько лучше такое решение чем "автоматическое" из С++. Дело в том, что память теряется куда чаще чем другие ресурсы. И ловить ее потери куда сложенее. Незарытый файл или хэндл проявляются довольно быстро, а вот утечки памяти — это бичь почти всех Win32-программ. К тому же с программиста как минимум снимается куча обязанностей по контролю.
S>>>argument-dependent name lookup,
VD>>Это я вообще не понял, что такое?
S>В MSDN загляни, оно там описано.
Где там? Что оно? Может по русски?
S>Когда один класс должен использовать одноименные классы из разных неймспейсов (особенно если внутри одной функции), просто необходимая вещь. Без него — только полная квалификация имен.
Вот я тебе и горю. Надуманная проблема. В жизни не всречается. По крайнй мере мне не всретилать пока.
S>Даже в VC 6.0 есть. using действует до конца области видимости — если оно не так, то это ошибак в компиляторе.
Ты про using namspace?
VD>>Уж лучще добавить With как в VB. Чтобы к членам объектов можно было обращаться через одну точку.
S>Ну это дело вкуса.
Это дело смысла. Точка (та что в VB) догогого стоит. Вон в пскале без нее и получается фигня. Как перекрывающиеся имена отличать?
S>Хотя как быть с операторами?
Да просто пережить. В крайнем случае .operator()...
S>Вот-вот, совершенно другая вещь, а назвали так же (и тем самым запретили тот, другой using). Уроды.
В данном случае согласен. Могли бы придумать другое название. Но это они по Струструпу. Чтобы не создавать дополнительных ключевых слов. Помнишь историю про = 0 для абстрактных методов вместо слова abstract? Тоже по уродски было и аргументировалось так же.
S>И что такого уродливого в указателях на методы класса? Совершенно логичная штука. Не, я не против, что бы в язык добавили чего-нибудь типа closure, но и без них не плохо.
Ну тогда может ты приведешь мне пример отличный от эмуляции делегатов (что тоже делает через одно место). А? Уродливо именно то что из полезного и удобного средства в С указатели на функции превратились в безмолезные уродливые кострукции.
S>Это кому как. Если я знаю, что сейчас в вектор или стрим буду много-много мегабайт запихивать, а потом все освобожу одним куском, то ручной распределитель памяти дает ускорение иногда аж в 500-1000 раз (C++ код, 30 мег данных пишутся в стрим в памяти).
Дык по сравнению с GC никакого выигрыша не будет. Там попросту нет освобождения пмяти. Она только занимается. Процесс сборки мусора происходит редко и тоже делается одним махом. Причем всгде, а не только в некторых случаях. В общем — это уже точно привычка, а не разумное требование.
S>А все проблемы и так всегда мои, если программу пишу я, а не MS Мне надо что-то вроде C++'ного uncaught_exception в деструкторе и нормальные деструкторы вместо finally, который все ООП рушит нафиг.
Чего он рушит? Это в С++ уродство полное. Надо же было не включить в стадарт finally! Почти все компиляторы это дело встроили, а Страуструп не чешется. На практике обработка ошибок в .NET на порядок поще, логичнее и удобнее чем в С++. Причем это теперь стандарт, а не самопальщина компилторостроителей. В С++ исключение живет в пределах одного модуля, нельзя намисать код обрабоки на VC, а лволи на BCC.
S>Хе-хе, вон в C++ спорные места до сих пор находят,
Нехрена было все так усложнять. Тогда и спорных мест не было бы.
S> а ты говоришь, что я, практически незнакомый с C#, за один раз все спорные места в нем нашел
А я тебе говрю, что в Шарпе все просто как три копейки. Для того он и делался.
S>И которая хуже воровства Ну не делаются сложные вещи простыми инструментами, и все тут. Вернее, делаются, он это сложнее, чем делать их более сложным инструментом.
И ты говоришь что это не демагогия?
VD>>Насклоько они будут мощны я пока не знаю. Но даже если они будут на уровне VC6, меня это устроит.
S>А меня, к сожалению, нет.
Дык првильно! Тебе же на них кривой язык переписывать. А мне просто не зависимые от конкретных типов алгортмы писать.
Здравствуйте Геннадий Васильев, Вы писали:
ГВ>Компонентно-ориентированное программирование.
ГВ>Подход к разработке, ориентированный на использование разных языков программирования
Использование разных языков программирования не является целью компонентной парадигмы. Так что "сборка ПО из готовых блоков." подходит больше.
ГВ>Примеры инфраструктур: COM, Corba Component Model (CCM), Любые plug-ins – тоже, в сущности, компоненты.
Я бы добавил Яву и .NET. В них компонентный подход вошел в общеупотребительную практику. По сути любой класс в этих системах является компонентом.
ГВ>Атрибутное программирование.
ГВ>Атрибутное программирование – описание свойств в терминах какой-либо инфраструктуры (атрибутах), располагающей информацией об использовании атрибутов.
Мое определение "декларативное) программирование — программирование где многие логические аспекты не прописываются в коде, а задаются в виде атрибутов" мне нравится больше.
ГВ>>Атрибутное программирование.
ГВ>>Атрибутное программирование – описание свойств в терминах какой-либо инфраструктуры (атрибутах), располагающей информацией об использовании атрибутов.
Vi2>Атрибутное программирование – это обрамление класса другими классами (без иерархии ИЛИ не составляющие с исходным классом никакой иерархии).
Про классы явно надумано. В COM-е небыло никаких классов.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте Aquila, Вы писали:
A>>Грузится, говоришь, быстрее? А я еще и программы запускаю.
VD>В общем, после твоих рассуждений о скорости, серьезно относиться к твоим рассужедениям о неприемлемости фреймворка нельзя.
В общем, после твоих рассуждений о скрости, с серьезно относиться к твоим рассужедениям о приемлемости фреймворка нельзя
Re[14]: Производительность Win2k на Duron 800/384...
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте Aquila, Вы писали:
A>>В свое время у меня был 486/24, на котором я гонял CBuilder 4. Меня тоже устраивало "время отклика". Ну и что? Тебя устраивало, а я тормоза не люблю. Был бы компьютер побыстрее, поставил бы Win2k, но не вижу никакого смысла , чтобы тратить деньги на апгрейд только ради этого. VD>Ты бы поставил, а потом трепался бы. На 300-х мегах W2k за всегда шустрее 98-х будет. Она эту память использовать умеет.
Да ставил я ее. Не понравилось.
A>>Зачем привыкать к тормозам? К тому же второй пункт (о том, что не работают нужные мне программы) играет не меньшую роль. Конечно, можно попробовать найти им замену, но... зачем? Зачем напрягаться, когда и так все работает, как нужно? Я люблю научнотехнический прогресс, но не за счет моих денег и времени и не вижу никакого смысла ставить новые версии ОС, если они не могут обеспечить того, что есть у меня уже сейчас . VD>Их твоих слов видно только одно. W2k ты видил только у других.
Я ее вижу каждый день на работе . Но там у меня компьютер побыстрее.
VD>А ХаРэ вообще не видил.
XPень я вообще ставить не буду. Большая, тормозная... Смысл ее ставить, если получаю тоже самое но с меньшими потерями?
