шаблоны С++ и дженерики С# - Философия программирования

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

ГВ>>Угу, всё равно у тебя по делу одна мысль: "C++ — отстой и маздай потому что отстой и маздай, .Net рулит потому что рулит". Хорошо, что есть что-то постоянное в этом мире.

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

А кто тут чем-то гордится? По-моему, неуёмная г... кхм, гордость и высокомерие замечены как раз за противниками C++.

VD>Скажем, если у компании есть много денег и ей нужно выпустить продукт критичный к объему используемых ресурсов и сильно оптимизированный под аппаратуру, а алгоритмически задачи не очень сложные, то С++ вполне себе инструмент. Но нужно понимать, что это альтернатива ассемблеру. Эдакий ассемблер с классами и шаблонами.

Нет, разумеется. Прежде всего, реальные преимущества C++ начинаются там, где начинаются его мнимые недостатки. Первый фактор — стабильность, надёжность и распространённость компиляторов; второй фактор — количество программистов; третий — возможность получать программы, которые не обязаны тащить за собой "фреймворк"; четвёртый — возможность получить быстрый бинарный код (не всегда, в прочем, реализованная в реальных программах); пятый — защищённость от декомпиляции; шестой — огромное количество библиотек на C и C++ и такая же распространённость интерфейсов к C.

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

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

VD>Не читай. Дженерики — это весьма абстрактное проектное решение. То что они были разработаны для платформы CLI (они, между прочем поддерживаются в Моно ни чем не хуже) ни как не мешает использованию их в других языках. Та же Ява имеет очень похожее решение.

А в каком месте джавовские дженерики компонентны? Там же type erasure — они не являются сущностью рантайма.

now playing: Oblivion — Marche (Boris Brejcha Mix)

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

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

ГВ>А кто тут чем-то гордится?

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

ГВ>По-моему, неуёмная г... кхм, гордость и высокомерие замечены как раз за противниками C++.

Кто что хочет, то и замечает.

VD>>Скажем, если у компании есть много денег и ей нужно выпустить продукт критичный к объему используемых ресурсов и сильно оптимизированный под аппаратуру, а алгоритмически задачи не очень сложные, то С++ вполне себе инструмент. Но нужно понимать, что это альтернатива ассемблеру. Эдакий ассемблер с классами и шаблонами.

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

Да, разумеется. Но, разумеется все останутся при своем мнении. Почему я говорю — пора завязывать.

ГВ>Прежде всего, реальные преимущества C++ начинаются там, где начинаются его мнимые недостатки.

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

ГВ> Первый фактор — стабильность, надёжность и распространённость компиляторов;

О, как? Тому противоречат масса вопросов совместимости которые можно увидеть на наших форумах.
Так что не надо выдавать желаемое за действительное.

ГВ> второй фактор — количество программистов;

По этому фактору Ява и даже дотнет (что спорно, но не суть) уже обогнали С++. И тенденция явно не в пользу С++.

ГВ> третий — возможность получать программы, которые не обязаны тащить за собой "фреймворк";

Это в точности такое же преимущество как и недостаток. Да и никогда не слышал, чтобы это было главным стимулом к програмированию на С++. Скажем у ОКамла и Хаскеля есть такое же приемущество, но это не останавливает многих не видеть их в упор.

ГВ> четвёртый — возможность получить быстрый бинарный код

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

ГВ>(не всегда, в прочем, реализованная в реальных программах);

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

ГВ>пятый — защищённость от декомпиляции;

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

ГВ> шестой — огромное количество библиотек на C и C++ и такая же распространённость интерфейсов к C.

Чушь полнешая. Один дотнет фрэймворк или ява содержат больше чем все дступные бесплатно С++-библиотеки. А уж поставщиков библиотек вообще предлагают универсальный код на любой вкус. К тому же С++-ники очень не охотно используют чужой код. И это оправдано. Совместимость чужого кода в С++ между собой очень фиговая. По этому обычно все заканчивается на STL и boost-е. Ну, возможно еще чем-то очень необходимого. Зато велосипедов в С++-проектах всегда выше крыши. Вряд ли это можно списать на тупость тех кто использует С++. Это побочные эффекты недостатков языка.

Ну, и все вышеперечисленное можно точно так же отнести скажем к Haskell-ю, OCaml-у, Lisp-у или D. Но почему-то выбирают С++. Мне кажется, что тут логично было бы применить принцип бритвы Окамма. Наиболее простое объяснение верно. А простое объяснение — это как раз то, что С++ — это очень распространенный высокоуровневый ассемблер позволяющий за счет усложнения и удорожания разработки добиться меньшего потребления ресурсов. Плюс, конечно, человеческая косность мышления и стереотипы.

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

А языковые изыски это точно не про С++. Человек выбирающий С++ из-за языковых изысков — это человек с очень узким кругозором и знаниями.

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

ГВ>...то дай, будь добр пруфлинк на "загибающуюся корбу" и сформулируй требования к идеальной компонентной среде. Требования должны быть получены каким-то иным путём, отличным от индукции из того, что ты увидел в .Net и JVM.

Лучше ты дай другой где бы корба использовалась. Или тупо пошукай по гуглю на слова "Is Corba dead?" или "Corba is dead".

Я за Корбой следил довольно давно и долго. С тех времен люди которые во всю популяризировали корбу перешли на яву, а про корбу забыли. То место где кораба должна была занять рынок сейчас занаяла Ява. И очень редко когда яво-вские АПИ опираются на корбу. В свое время Борланд развивал эту тему, но мирно почил вместе со своими идеями. В прочем, формально Борланд тоже жив...

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

EC>А в каком месте джавовские дженерики компонентны? Там же type erasure — они не являются сущностью рантайма.

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

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

EC>>А в каком месте джавовские дженерики компонентны? Там же type erasure — они не являются сущностью рантайма.

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

VD>Их легко можно реализовать в компонентах и на них легко можно устраивать компонентные абстракции.
Можно эту фразу пояснить? Обе её части.

now playing: Deadmau5 — The 16th Hour

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

VD>>Они не противоречат компонентным идеям.
EC>Это аргумент в пользу компонентности?

Это обяснение, почему в Яве такие жденерики, а не С++-ные шаблоны.
Ты тему то читал?

VD>>Их легко можно реализовать в компонентах и на них легко можно устраивать компонентные абстракции.
EC>Можно эту фразу пояснить? Обе её части.

Какие из букв тебе не ясны?

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

VD>>>Они не противоречат компонентным идеям.
EC>>Это аргумент в пользу компонентности?
VD>Это обяснение, почему в Яве такие жденерики, а не С++-ные шаблоны.
VD>Ты тему то читал?
А то. Меня заинтересовало вполне конкретное утверждение:

VD>>Дженерике же проектировались с расчетом на компонентные решения.

Хочу понять в каком месте джавовские дженерики компонентны.
Я вот знаю в каком .NET'ные компонентны, а джавовские — нет.
И как относятся С++-ные шаблоны к компонентности дженериков?

VD>>>Их легко можно реализовать в компонентах и на них легко можно устраивать компонентные абстракции.
EC>>Можно эту фразу пояснить? Обе её части.
VD>Какие из букв тебе не ясны?
Мы вроде говорим на вполне определённую техническую тему, а ты какой-то туман напускаешь когда тебе конкретный вопрос задают.
Не настроен общаться конструктивно — на здоровье, никто не неволит.

now playing: Maxime Dangles — Automne Bizard

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

VD>Чушь полнешая. Один дотнет фрэймворк или ява содержат больше чем все дступные бесплатно С++-библиотеки.

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

VD>Со своей стороны предлагаю привести "пруф линк" подтвердающий утверждение, что компонентных "инфраструктур" мириады. Устрит даже список из 20-30 реализаций. Мириады не надо приводить.

.

Я возьму ссылку из твоего соседнего сообщения: http://en.wikipedia.org/wiki/Component-oriented_programming

В конце статьи как раз порядка двух десятков ссылок на компонентные инфраструктуры.

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

ГВ>>...то дай, будь добр пруфлинк на "загибающуюся корбу" и сформулируй требования к идеальной компонентной среде. Требования должны быть получены каким-то иным путём, отличным от индукции из того, что ты увидел в .Net и JVM.
VD>Лучше ты дай другой где бы корба использовалась.

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

VD>Или тупо пошукай по гуглю на слова "Is Corba dead?" или "Corba is dead".

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

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

Ничего не понятно. Что за люди, какое место, почему явовские API должны опираться на корбу? "Есть у нас оружие!" (c)

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

ГВ>>Нет, разумеется.
VD>Да, разумеется. Но, разумеется все останутся при своем мнении. Почему я говорю — пора завязывать.

Ладно, ещё по постингу и завязываем.

Тем более, что разговор уже уходит в вечно больную сторону "C++ vs VladD2".

ГВ>> Первый фактор — стабильность, надёжность и распространённость компиляторов;
VD>О, как? Тому противоречат масса вопросов совместимости которые можно увидеть на наших форумах.
VD>Так что не надо выдавать желаемое за действительное.

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

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

ГВ>> второй фактор — количество программистов;
VD>По этому фактору Ява и даже дотнет (что спорно, но не суть) уже обогнали С++. И тенденция явно не в пользу С++.

Ладно, на счёт количества программистов я загнул. Их просто так же (не-)просто найти, как порядочных Java- и .Net-программистов. А в том, что в целом Java- и .Net-программистов должно быть больше, чем "плюсовиков" я ни минуты и не сомневаюсь. Причины ты и сам отлично знаешь.

ГВ>> третий — возможность получать программы, которые не обязаны тащить за собой "фреймворк";
VD>Это в точности такое же преимущество как и недостаток. Да и никогда не слышал, чтобы это было главным стимулом к програмированию на С++. Скажем у ОКамла и Хаскеля есть такое же приемущество, но это не останавливает многих не видеть их в упор.

Угу, поскольку есть ещё соображение N6.

ГВ>>пятый — защищённость от декомпиляции;
VD>Это совсем глупый домысел. Покажи пример того как компания пострадала от декомпиляции управляемого кода.

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

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

Конечно. Всё дело в цене на билет.

ГВ>> шестой — огромное количество библиотек на C и C++ и такая же распространённость интерфейсов к C.

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

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

VD>Ну, и все вышеперечисленное можно точно так же отнести скажем к Haskell-ю, OCaml-у, Lisp-у или D. Но почему-то выбирают С++. Мне кажется, что тут логично было бы применить принцип бритвы Окамма. Наиболее простое объяснение верно. А простое объяснение — это как раз то, что С++ — это очень распространенный высокоуровневый ассемблер позволяющий за счет усложнения и удорожания разработки добиться меньшего потребления ресурсов. Плюс, конечно, человеческая косность мышления и стереотипы.

Так... Опять сказка про белого бычка. Ладно, мнение есть мнение. Мни, раз мнится.

ГВ>>А вот потом уже — языковые изыски, паттернопарадигмы и прочая дребедень.
VD>А языковые изыски это точно не про С++. Человек выбирающий С++ из-за языковых изысков — это человек с очень узким кругозором и знаниями.

Не, ты не понял. Языковые изыски — это вообще отдельная штука.

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

ГВ>Вопросы совместимости возникают везде, где декларируется совместимость.

В принципе, проблем с переносом особых нет, если не используются vendor-specific конструкции. Да
ГВ>Мда, ну и каша же у тебя в голове по поводу C++, во всяком случае. На самом деле, C++ world'09 уже очень сильно отличается от того, из которого ты уходил... Сколько там лет назад? А проблемы новичков или не отработанных библиотек — они во все времена одни и те же. С совместимостью тоже, в общем и целом особых проблем нет, если библиотека написана без использования специфики GCC, MSVC, ICC и т.п. Так что, что-то ты тут либо преувеличиваешь, либо пользуешься впечатлениями в прямом смысле седой старины. С "велосипедами" ситуация примерно та же — с развитием буста большинство велосипедов корова языком слизала. Так что, прекращай уже повторять замшелые стереотипы, это вредно в смысле косности мышления.

Как интересно. И что, уже есть какой-то устоявшийся стандарт на представление хотя бы аналогов DateTime и TimeSpan? Или по-прежнему каждая библиотека использует своё уникальное видение мира? А строки — уже решили, как надо делать? Или по-прежнему в QString нет конструктора от CString, и оба несовместимы с std::string?

Может быть, есть какой-то стандарт на интерфейс к XML парсеру / XSLT трансформатору? Или опять-таки смена одной либы на другую потребует массового исправления исходников программы?
Кстати, этот парсер — он какие строки возвращает?

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

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

S>Как интересно. И что, уже есть какой-то устоявшийся стандарт на представление хотя бы аналогов DateTime и TimeSpan? Или по-прежнему каждая библиотека использует своё уникальное видение мира? А строки — уже решили, как надо делать? Или по-прежнему в QString нет конструктора от CString, и оба несовместимы с std::string?

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

S>Может быть, есть какой-то стандарт на интерфейс к XML парсеру / XSLT трансформатору? Или опять-таки смена одной либы на другую потребует массового исправления исходников программы?
S>Кстати, этот парсер — он какие строки возвращает?

Смена одной либы на другую очень часто требует переработки исходников.

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

ГВ>Я возьму ссылку из твоего соседнего сообщения: http://en.wikipedia.org/wiki/Component-oriented_programming

ГВ>В конце статьи как раз порядка двух десятков ссылок на компонентные инфраструктуры.

Где же ты там два десятка усмотрел? Или ты технологии по ссылкам считаешь?

Ты попробуй, все же, списочек то составить...

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

ГВ>Я возьму ссылку из твоего соседнего сообщения: http://en.wikipedia.org/wiki/Component-oriented_programming

ГВ>В конце статьи как раз порядка двух десятков ссылок на компонентные инфраструктуры.

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

Component-oriented programming
    * SOFA component system [1] from ObjectWeb
    * Fractal component model [2] from ObjectWeb
    * rCOS method of component-based model driven design [3] from UNU-IIST
    * Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft
    * XPCOM from Mozilla Foundation
    * VCL and CLX from Borland and similar free LCL library.
    * Enterprise JavaBeans from Sun Microsystems
    * UNO from the OpenOffice.org office suite
    * Eiffel programming language
    * Oberon programming language and BlackBox
    * Bundles as defined by the OSGi Service Platform
    * The System.ComponentModel namespace in Microsoft .NET
    * Flow-based programming
    * MidCOM[4] component framework for Midgard and PHP
    * Common Component Architecture (CCA) - Common Component Architecture Forum [5], Scientific/HPC Component Software
          o TASCS [6] - SciDAC [7] Center for Technology for Advanced Scientific Component Software

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

ГВ>>Я возьму ссылку из твоего соседнего сообщения: http://en.wikipedia.org/wiki/Component-oriented_programming

ГВ>>В конце статьи как раз порядка двух десятков ссылок на компонентные инфраструктуры.

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

VD>

VD>Component-oriented programming
VD>    * SOFA component system [1] from ObjectWeb
VD>    * Fractal component model [2] from ObjectWeb
VD>    * rCOS method of component-based model driven design [3] from UNU-IIST
VD>    * Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft
VD>    * XPCOM from Mozilla Foundation
VD>    * VCL and CLX from Borland and similar free LCL library.
VD>    * Enterprise JavaBeans from Sun Microsystems
VD>    * UNO from the OpenOffice.org office suite
VD>    * Eiffel programming language
VD>    * Oberon programming language and BlackBox
VD>    * Bundles as defined by the OSGi Service Platform
VD>    * The System.ComponentModel namespace in Microsoft .NET
VD>    * Flow-based programming
VD>    * MidCOM[4] component framework for Midgard and PHP
VD>    * Common Component Architecture (CCA) - Common Component Architecture Forum [5], Scientific/HPC Component Software
VD>          o TASCS [6] - SciDAC [7] Center for Technology for Advanced Scientific Component Software
VD>

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

Component-based software frameworks for specific domains
    * Earth System Modeling Framework (ESMF)
Compound document technologies
    * Bonobo (component model), a part of GNOME
    * KPart, the KDE Compound document technology
    * Object linking and embedding (OLE)
    * OpenDoc
    * Fresco
Business object technologies
    * Newi
Distributed computing software components
    * 9P distributed protocol developed for Plan 9, and used by Inferno and other systems.
    * CORBA and the CORBA Component Model from the Object Management Group
    * D-BUS from the freedesktop.org organization
    * DCOM and later versions of COM (and COM+) from Microsoft
    * DCOP from KDE
    * DSOM and SOM from IBM (now scrapped)
    * ICE from ZeroC
    * Java EE from Sun
    * .NET Remoting from Microsoft
    * Web Services
          o REST
    * Universal Network Objects (UNO) from OpenOffice.org
    * Zope from Zope Corporation

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	24.09.09 17:35
Оценка:	+3

	От:	EvilChild
	Дата:	24.09.09 18:42
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	24.09.09 19:11
Оценка:

От:	VladD2	www.nemerle.org
Дата:	24.09.09 19:14
Оценка:

От:	VladD2	www.nemerle.org
Дата:	24.09.09 19:17
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	25.09.09 11:41
Оценка:	+1