Чем так привлекателен C++ ? - Философия программирования

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

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

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

Раз не ты выбирал — вопрос снимается.

ГВ>> Мне это интересно, поскольку я Java обходил за километр. Да и сейчас обхожу. И в основном — из-за одиночного наследования, с которым практически познакомился (и натрахался по уши) ещё на Turbo-Pascal 5.5.
AVK>Ну во первых TP 5.5 был первым объектным вариантом паскаля, первый рабочий был 7.0. Во вторых то что ты не умеешь проектировать без множественного наследования еще не означает что без него жить нельзя. Я писал и на паскале, и на джаве, теперь вот на дотнете. И как ни странно от отсутствия множественного наследования не страдаю. Шаблоны действительно иногда позволяют повысить эффективность выполнения, но вот множественное наследование бывает полезным в очень небольшом количестве случаев, жа и те по большей части ограничиваются множественным наследованием интерфейсов, которое и в джаве и в дотнете есть.
AVK>А вобще забавно — по TP 5.5 судить о джаве и дотнете

Модели наследования очень уж похожи. А насчёт проектирования без множественного наследования — не кипятись, эмулировать такое наследование через агрегацию я умею, хоть и не люблю. Ладно, давай закроем тему про TP.

ГВ>>Говорит, но я Java всё ещё стороной обхожу по-возможности.

Причина — выше.
AVK>Глупая причина надо сказать.

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

ГВ>>Как подкласс value-type-ов. До чего только оптимизация не доводит.

Да, наворочено до небес. Это интересно выглядит с позиций C++ — программирования, где, как я помню, всё-таки стремятся унифицировать концепции, сведя всё к классам. Это, кстати, и в мануалах по C++ было: "в C++ все типы — классы".
AVK>Ага, int в С++ тоже класс?

Нет, конечно, физически int — не тоже самое, что и класс, тут главное — акцент на унифицированное представление в мозгах. Что-то вроде "воспитания" пользователей (программистов).

ГВ>> С этой позиции Java гораздо лучше C# (концептуально), хотя и хуже, чем C++ (как концептуально, так и по быстродействию).
AVK>Вот о чем не знаешь не говори. Гораздо хуже. Та же самая песня — примитивные типы сами по себе, классы сами по себе. Можешь поглядеть на EJB — сколько там наворочено из-за того что есть примитивные типы.

И нет шаблонов...

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

Софистика и демагогия чистой воды. Например, в C++ преобразования "туда и оттуда" совсем не аналогичны Javа, сам это прекрасно знаешь. И чем в данном случае .NET намного лучше? Вообще — как это всё логически связано?

ГВ>>По сути, проблемы, связанные с GC и его влиянием на проектирование никуда не делись. Только теперь придётся думать ещё и о том, где вводить value-, а где class-type.
AVK>Проблем GC решает куда больше.

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

ГВ>>Обрати внимание, что от структур на C++ очень даже можно унаследоваться, чего нельзя сделать от C#-структур.
ГВ>> Они — sealed по определению.
AVK>Естественно, у них же vtbl нету. Структура она и есть структура. Кусок памяти просто.

Обрати внимание не терминологию — она сугубо "сишная". Это просто наблюдение...

AVK>>>Ну и что? А в шарпе структура и int вобще не отличаются.

ГВ>>В смысле — как ипостаси value-type? Ну да, согласен. ИМХО, концептуально — кошмар, поскольку вместо разделения "элементарный тип/класс" (C++)
AVK>Ты сам себе противоречишь — то у тебя главный недостаток шарпа в том что у него типы не унифицированны, то главный недостаток что они унифицированны. Помоему ты уже споришь ради спора, поскольку вместо аргументов в ход пошла софистика.

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

ГВ>>вводится дополнительная градация: "элементарный тип/структура/класс". Собственно говоря, именно это я и имел ввиду.
AVK>Во первых не там никакой градации. Любые данные я могу привести к object. А потом — ты скромно умалчиваешь что в С++ есть указатели на экземпляры, а есть экземпляры классов. Те же яйца вид в профиль.

В данном случае указатели и ссылки я не рассматривал. Кстати, в C# тоже есть ref (аналог &), params (маршализуемый аналог эклипсиса), out (в C++ предусмотрена защита от модификации параметра, переданного по указателю через модификатор const).

AVK>>>То что? У самого загруженного сервера нагрузка все равно неравномерна.
ГВ>>Да, только ему наверняка потребуется мусор выбрасывать именно в моменты пиковой нагрузки. Это просто из логики функционирования GC следует.
AVK>Ну ты понимаешь что люди тестировали, и даже при стрессовых нагрузках GC оказывался быстрее сишного хипа. Единственный недостаток GC — непрогнозируемость задержек. Поэтому ни джава ни дотнет не могут применяться в рилтайм системах.

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

AVK>>>Ну в прошлом же сообщении тебе привел вполне конкретный пример — компиляция бизнес логики на лету. Или еще более конкретно — аналог jsp/asp.net.
ГВ>>Ты имеешь ввиду описанную тобой ERP или что-то ещё?
AVK>Это не я описывал.

Здравствуйте!

Перечитай свои же постинги про 90% форм, генерируемых на Java.

ГВ>> Если классы, то они автоматически удалятся при выгрузке библиотеки, а если объекты, то они будут удалены перед выгрузкой или во время уничтожения статических данных модуля. Это уже детали проектирования в конкретном контексте конкретного App-сервера.
AVK>А ты пробовал? Вот идиоты COM придумали, оказывается сишные классы без него прекрасно на лету подгружаются. В общем то что ты предлагаешь даже не смешно. Подумай хотя бы о том что произойдет если базовый класс в одной dll а потомок в другой.

Здесь ограничения в самом деле получаются подобными COM-овским. Однако, я не утверждаю (и не буду утверждать), что каждый класс обязан быть подгружаемым компонентом. Компоненты — это deployment.

AVK>>>Сервисы ты эти как реализовывать будешь?
ГВ>>Как часть App-сервера и комплект драйверов. Под "сервисами" я имею ввиду сугубо системные аспекты — коммуникации, систему безопасности и т.п.
AVK>Опять общие слова. Это все можно сказать про любое средство разработки.

Я говорил не о средстве разработки, а об архитектуре системы, не передёргивай, please.

AVK>>>И умеющее работать в глобальной сети. Веб-сервисы это тоже веб-приложение.
ГВ>>А к чему фраза: "умеющее работать в глобальной сети"? Какая разница для приложения — глобальная сеть или локальная?
AVK>Вот сразу видно что ты никогда не писал эти самые работающие в глобальной сети. Разница есть — в величине и предсказуемости задержек, вероятности обрыва, толшине канала и т.д. Вот в обратную сторону пожалуйста — из глобальной сети в локальную.

То, о чём ты сказал — не самое интересное. Самое интересное, ИМХО, — сохранение состояний интерфейса пользователя между вызовами.

ГВ>>Это вообще с точки зрения прикладной логики должно быть глубоко фиолетово, поскольку это — сугубо компьютерная, а не прикладная специфика. Сие есть забота сетевых драйверов и прочих коммуникационных прослоек (в т.ч. — ORB, DCOM и т.п.).
AVK>Все это ты красиво говоришь, только при чем тут С++. И что из тобой перечисленного нельзя реализовать на джаве, дотнете?

Я же не говорю, что это принципиально невозможно реализовать на Java или .NET! Да хоть на Вижуал Васике и Fortran! Речь-то шла об архитектуре системы и подходе к её построению. ИМХО, очень хреново, если на верхнем уровне проектирования присутствует разделение понятий Web-интерфейс и Windows-интерфейс. Краткое обоснование я уже приводил.

AVK>>>Ты уверен? Ты хорошо представляешь что такое веб-интерфейс. Я вот представляю — логика совершенно иная.
ГВ>>Твоя фраза "логика совершенно иная", ИМХО, свидетельствует о том, что ты невнимательно прочитал мою фразу. Я же ясно сказал — "...с точки зрения приложения". Так что, извини, но я считаю твой довод попросту неправомерным.
AVK>С точки зрения приложения логика совершенно иная.

Приехали.

Перечитать ещё раз моё сообщение — ну никак. И обоснование двумя строками ниже — совсем нет. Нам бы сначала за меч схватиться, а там разберёмся! Так что-ли?

ГВ>>Кратко обосную свой взгляд.

ГВ>> Но прикладная логика не должна быть завязана на эти аспекты! Это противоречит всем принципам "правильного" модульного проектирования, которые сами по себе рационально обоснованы, иначе не были бы общепризнанными.
AVK>ВОт ты попробуй воплотить свои красивые и правильные идеи в жизнь, а потом и будешь всем тут рассказывать как что и почему. До сих пор все попытки привести веб-интерфейсы к GUI оканчивались печально. Что то получилось у MS с вебформсами, но это еще далековато до реального написания приложения которое будет переключаться прозрачно с веб-интерфейса на GUI. Пока что все ограничивается общим ядром, а интерфейс пишется под гуй отдельно, под веб отдельно.

Это можно считать аргументом? Если да, то он неправомерен, поскольку сие — аргумент к коллективу.

Предлагаю постановить, что доводы типа: "а ты попробуй, знаешь как это трудно!" — не котируются, если не снабжены дополнительными разъяснениями о том, что именно считается трудным. Я во всяком случае на подобные выпады больше отвечать не буду. Понимаешь ли, для меня выражение "трудно, но можно" означает, что я так и сделаю, потому что "можно".

ГВ>> А то, что подход, искажающий подобное деление распространён более чем широко — так это не означает, что он верен.
AVK>Ну да, мы ж умнее, мы пойдем своим путем. А все эти jsp, asp.net фигня полная. Все правильно.

В корень зришь!

ASP — это не "полная фигня" ни в коем случае, но уже тепло.

ГВ>>Человек (в данном случае я имею ввиду проектировщика) в каком-либо контексте всегда делает ошибок больше, чем корректных действий, особенно — поначалу. А ошибки (а смешение абстракций в данном случае — ошибка) могут провоцироваться разными факторами — и маркетинговой активностью (которая почти всегда связана с психологическим давлением посредством, в частности, методом спекуляций на теме "старое/новое") — в том числе.
AVK>Ну да, во всех бедах виноваты маркетологи. Это как в старом анекдоте — если ты такой умный, то почему ж не богатый?

Я сказал — "и маркетинговой активностью... в том числе", а не "только ей", что подразумевается первой частью твое фразы.

ГВ>>Банальный пример следствий — помещение прикладной логики в обработчик OnClick. Таким образом всегда делается грубейшая ошибка, поскольку изменения в соответствующем элементе интерфейса пользователя повлияют на прикладную логику. Совокупность таких ошибок рождает непереносимую программу и колоссальное её усложнение.
AVK>А при чем здесь средства разработки. Ты не уходи от темы.

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

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

AVK>>>Ну да — все вокруг идиоты, повелись на рекламу. Настоящие кульные приложения надо писать на ц плус плус. Ты ради интереса напиши на С++ аналог rsdn.ru, я думаю просветление наступит быстро.
ГВ>>Эмоции... Кроме того — невыдержанность и хамство, извини за прямоту.
AVK>Это тиы так воспринимаешь. Не стоит. И все же — напиши. Хотя бы начни.

Хорошо, возможно, для тебя такая форма общения — с постоянным передразниванием и попытками унижения оппонента — норма. Учту. Собственно, уже учёл.

ГВ>> Ты обратил внимание, что я слово "ненависть" в кавычки взял? И ещё небольшая подковырка: а чего это RSDN стал так часто глючить?

AVK>То что его почти полностью переписали практически с нуля. Можешь у IT спросить сколько у него ушло на это чистого времени. А потом попробуй сделать тоже на С++ за время в два раза большее.

IT уже сказал "своё веское".

AVK>>>Кто бы спорил. Я пытаюсь сказать что математика не должна определять все остальное.

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

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

ГВ>> Куда от этого денешься? Так что, где компьютеры — там и математика и использующие её формальные дисциплины (формальная семантика, формальная логика и т.п). И никуда мы от этого не денемся. ИМХО, вместо "математически", мне стоило употребить термин "формально".
AVK>Есть такая наука — системотехника. Так вот — во всех учебниках там ясно написано — аналитическая модель сложных систем на данном уровне развития науки невозможна. Получается описать аналитически только очень простые системы. Вот такие вот пирожки.

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

ГВ>>А кроме того — ИМХО, ты спекулируешь выражением "учиться" и "новизна". Я охотно изучу новую концепцию или перечитаю Ульмана, а вот копаться в очередных приблудах и API просто любопытства ради... извините. Тем более, что из моих собеседников, только ты, IT, да Влад активно защищают .NET. Другие мои знакомые писали на нём. И знаешь, — плевались... Вернулись на C++.
AVK>Я тебе отвечу твоими же словами — не умеют строить абстракции. Да и потом — непонятно когда они только успели пописать, поплеваться и вернуться обратно. Релиз только в феврале вышел. Просто видимо они писали 2 дня, не разобрались и вернулись на старое. Вон Влад тоже первое время говорил что дотнет это по большей части фигня полная. Однако у него хватило ума не бросать а разобраться.

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

AVK>>>Тока эти внешние средства есть во всех приложениях.
ГВ>>Да, и что это меняет? Если необходимо обеспечить переносимость информации, то проблема с порядком байтов в int или float — далеко не самая важная. Кроме того, есть ещё горы библиотек для C++.
AVK>Меняет это одно — переносимые программы на С++ писать тяжело.

Всё зависит от того, как выбраны основные абстракции и как они эволюционируют. Это, ИМХО — ключ ко многим проблемам разработки софта.

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

По этому поводу хорошо проезжался, кажется, Алан Картер с Progstone (http://progstone.narod.ru — русский вариант сайта, более точно ссылку указать не смогу — то ли где-то в материалах, то ли в рассылках, но суть не в этом). Посмотри там. Конкретно, там была фраза типа такой: "они [представители NASA] сказали, что будут совершенствовать процесс и дальше". Это в ответ на потерю аппарата. Что можно сказать — молодцы!

Наверное, им стоило на Java софт написать — тогда бы он вообще не взлетел

) Или на .NET — чтобы взлетел неизвестно когда. Шутка.

Просто твой довод абсолютно "не в тему".

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

ГВ>Модели наследования очень уж похожи. А насчёт проектирования без множественного наследования — не кипятись, эмулировать такое наследование через агрегацию я умею, хоть и не люблю.
Это еще не известно кто кого эмулирует, агрегация мн или мн агрегацию

ГВ>Не настаиваю на однозначной её оценке всеми, но тем не менее, для меня поддобное ограничение оказалось существенным. А поскольку я был свободен в выборе инструментария, то и отказался от Java.
Пословицу про молоко и воду помнишь?

AVK>>Вот о чем не знаешь не говори. Гораздо хуже. Та же самая песня — примитивные типы сами по себе, классы сами по себе. Можешь поглядеть на EJB — сколько там наворочено из-за того что есть примитивные типы.
ГВ>И нет шаблонов...

Нет. Там шаблоны в том виде в каком они в С++ и не помогут, тут нужен те самый generic types, которые шаблоны, но в рантайме.

AVK>>Проблем GC решает куда больше.
ГВ>С твоей точки зрения — "больше решает", с моей — "больше создаёт". Частичное подтверждение моей точки зрения я нашёл в твоих словах ниже о непредсказуемости задержек.
Тогда рассказывай какая у тебя предметная область.

AVK>>Естественно, у них же vtbl нету. Структура она и есть структура. Кусок памяти просто.
ГВ>Обрати внимание не терминологию — она сугубо "сишная". Это просто наблюдение...
Где ты тут сишную терминологию увидел?

ГВ>В данном случае указатели и ссылки я не рассматривал. Кстати, в C# тоже есть ref (аналог &), params (маршализуемый аналог эклипсиса), out (в C++ предусмотрена защита от модификации параметра, переданного по указателю через модификатор const).

params то тут при чем? Чистейшей воды синтаксическая конструкция.

ГВ>Про realtime-системы совершенно согласен. (Стакан в студию!) Я именно непрогнозируемость задержек и имел ввиду. Кстати, я не думаю, что это критично в любом приложении, но нервов может попортить много.
Не вижу как это может попортить нервы в серверах приложений к примеру. Непредсказуемость это не значит что GC прервет работу программы на десятки секунд.

ГВ> Кстати, управление технологическим процессом я бы такой системе не доверил.
А это смотря какие ТП. Если они некритичны к запаздыванию в единицы секунд то очень интересный вариант платформы.

AVK>>А ты пробовал? Вот идиоты COM придумали, оказывается сишные классы без него прекрасно на лету подгружаются. В общем то что ты предлагаешь даже не смешно. Подумай хотя бы о том что произойдет если базовый класс в одной dll а потомок в другой.

ГВ>Здесь ограничения в самом деле получаются подобными COM-овским. Однако, я не утверждаю (и не буду утверждать), что каждый класс обязан быть подгружаемым компонентом. Компоненты — это deployment.
Для объектов бизнес-логики это обязательное условие.

AVK>>Опять общие слова. Это все можно сказать про любое средство разработки.
ГВ>Я говорил не о средстве разработки, а об архитектуре системы, не передёргивай, please.
А С++ то ту при чем?

ГВ>То, о чём ты сказал — не самое интересное. Самое интересное, ИМХО, — сохранение состояний интерфейса пользователя между вызовами.
Вот поэтому веб интерфейс так сильно отличается от гуя.

ГВ>Я же не говорю, что это принципиально невозможно реализовать на Java или .NET! Да хоть на Вижуал Васике и Fortran! Речь-то шла об архитектуре системы и подходе к её построению. ИМХО, очень хреново, если на верхнем уровне проектирования присутствует разделение понятий Web-интерфейс и Windows-интерфейс. Краткое обоснование я уже приводил.
Хреново, не хреново, но разделение присутствует, иначе либо гуй фиговый, либо веб-интерфейс. Вот только непонятно что ты под верхним уровнем понимаешь. Интерфейсную логику в ялдро системы тащить конечно не надо. А вот презентативная логика получается разной.

ГВ>Это можно считать аргументом? Если да, то он неправомерен, поскольку сие — аргумент к коллективу.
Это ты так считаешь. Все же я не готов поверить что ты вот сядешь и напишешь лучше чем все остальные писали до этого.
Это самые правильные аргументы — факты в голом виде.

ГВ>Предлагаю постановить, что доводы типа: "а ты попробуй, знаешь как это трудно!" — не котируются, если не снабжены дополнительными разъяснениями о том, что именно считается трудным. Я во всяком случае на подобные выпады больше отвечать не буду. Понимаешь ли, для меня выражение "трудно, но можно" означает, что я так и сделаю, потому что "можно".
Просто устал я за тобой замечать незнание что такое дотнет. И если ты такой упорный то бог бы с ним, это твое личное дело. Но ты ведь новичкам советуешь не пользоваться дотнетом, даже не попробовав сам.

AVK>>Ну да, мы ж умнее, мы пойдем своим путем. А все эти jsp, asp.net фигня полная. Все правильно.
ГВ>В корень зришь!

ASP — это не "полная фигня" ни в коем случае, но уже тепло.
А ты его пробовал?

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

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

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

AVK>>Это тиы так воспринимаешь. Не стоит. И все же — напиши. Хотя бы начни.
ГВ>Хорошо, возможно, для тебя такая форма общения — с постоянным передразниванием и попытками унижения оппонента — норма. Учту. Собственно, уже учёл.

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

AVK>>То что его почти полностью переписали практически с нуля. Можешь у IT спросить сколько у него ушло на это чистого времени. А потом попробуй сделать тоже на С++ за время в два раза большее.
ГВ>IT уже сказал "своё веское".

Ну это он скромничает.

AVK>>Компьютер это не сферический конь в вакууме. Программы пишуться не ради программ а ради реального мира. И нет там никакой детерминированности. А еще есть такой раздел прикладной науки как надежность вычисления. Так вот, там априори считается что комп подвержен случайным ошибкам.
ГВ>К чему ты это?
К тому что комп недетерминирован.

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

ГВ>Угу. Только с целью обеспечения "постижимости" в общем и возможности аналитического описания в частности. как раз и говорится, что нужно разбивать сложные системы на простые подсистемы, для которых и строится то или иное формальное описание. И для их взаимодействий — тоже.
вот как тебя не обидеть? — скажем так мягко, ты не прав, не все можно разбить на простейшие подсистемы.
AVK>>Меняет это одно — переносимые программы на С++ писать тяжело.

ГВ>Всё зависит от того, как выбраны основные абстракции и как они эволюционируют. Это, ИМХО — ключ ко многим проблемам разработки софта.
Зависит. Но в итоге на джаве получается проще.

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

<<... J 1.0 alpha 4 >>

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

ГВ>А к чему фраза: "умеющее работать в глобальной сети"? Какая разница для приложения — глобальная сеть или локальная? Это вообще с точки зрения прикладной логики должно быть глубоко фиолетово, поскольку это — сугубо компьютерная, а не прикладная специфика. Сие есть забота сетевых драйверов и прочих коммуникационных прослоек (в т.ч. — ORB, DCOM и т.п.).
ГВ>>>Так вот, ИМХО, что Web-интерфейсы, что Windows-UI+что-то-там сеть — всё едино с точки зрения приложения, поскольку прикладная логика от этого не должна изменяться (Если меняется, то это — бардак)

Вот именно, интерфейс это мелочь, главное прикладная логика, которая не должна сильно меняться от типа приложения (настольное, WEB,..).
А теперь вопрос на засыпку: Допустим ты написал на супер универсальном языке C++, очень универсальные классы с прикладной логикой. Каким образом ты собираешься запихнуть свои труды в процесс WEB-сервера (или другого сервера, или если другой программе захочется подергать за твое хозяйство).
Единственное более менее вменяемое решение для этого — COM,DCOM.
Во что превращается прикладная логика когда кней привинчивают COM,ATL? Это довольно печальное зрелище.
Вот мне бы это и хотелось услышать от противников .NET,С#,Java примерно такую фразу:
"реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET"

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

AVK>>>>Ну я то тебе как раз попробовать что нибуть написать для дотнета советовал.
ГВ>>>Да вот я и думаю — стоит на него тратить время сейчас или подождать выхода версии 6.0 ?

Ой не знаю дождешся ли 6 версии .NET программируя на C++. Я имею ввиду доживет ли C++ до 6 версии .NET ????
В последние годы ява заметно потеснила C++, теперь M.soft его добил. От силы 4-5 лет и все, останутся для C++ драйвера, и программирование контроллеров (повышение производительности ПК только усугубляет положение C++).

Тут спор не в синтаксисе языков а в уровне абстракции.
Я тоже с ностальгией вспоминаю времена, когда сидя в DOC на Borland C++ 2.0, поковыряв программу в TurboProfiler, можно было сделать умное выражение лица, написать asm{..}, поднапрячь интелект, решив сложную комбинаторную задачу, по хитрому соптимизировать какую нибудь сортировку,распихать по регистрам, ... и с чувством глубокого удовлетворения наблюдать как прога стала "летать". Теперь такой уровень ни кому не нужен.

Скоро станет не нужно и то что делалось на C++ в последние 5 лет.Возможности повторного использования кода у такого подхода очень слабые. Может это и интересно писать всякие эффективные хитрые алгоритмы сортировок, склеивания копирования строк, и.т.д., но они уже написаны, зачем каждый раз делать одно и тоже?. По крайней мере этим бубут заниматься очень не многие.

А для более высокого уровня C++ не приспособлен.

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

SS>А для более высокого уровня C++ не приспособлен.

Всё правильно, только боюсь что ГВ этот твой постинг аккуратненько проигнорирует

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

[...]
AVK>Ну и небольшой совет — если будет время ты все же попробуй реализовать на дотнете какой нибудь небольшой проектик из тех которые ты писал на С++.

AVK>И не обижайся, никаких личных к тебе претензий и наездов у меня нет.

У меня тоже. Но всё равно спор, ИМХО, неплохой вышел. Спасибо.

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

SS>Во что превращается прикладная логика когда кней привинчивают COM,ATL? Это довольно печальное зрелище.

В прикладную логику с подключённой "толстой" интерфейсной прослойкой. То есть, в то, во что она и должна превратиться в этом случае.

SS>Вот мне бы это и хотелось услышать от противников .NET,С#,Java примерно такую фразу:
SS>"реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET"

Это от объёма задачи зависит. Чем она больше — тем важнее унификация внутренней структуры и глубина проработки абстракций. Тем адекватнее там C++.

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

Концептуально — частный случай, фактически — COM и ORB распространены очень широко. Теперь к ним добавляется .NET. Но это ничего не меняет.

AVK>>>>>Ну я то тебе как раз попробовать что нибуть написать для дотнета советовал.
ГВ>>>>Да вот я и думаю — стоит на него тратить время сейчас или подождать выхода версии 6.0 ?

SS>Ой не знаю дождешся ли 6 версии .NET программируя на C++. Я имею ввиду доживет ли C++ до 6 версии .NET ????

Да C++-то доживёт. А вот доживёт ли .NET не мутировав во что-то ещё "очень новое" — абсолютно не уверен.

SS>В последние годы ява заметно потеснила C++, теперь M.soft его добил. От силы 4-5 лет и все, останутся для C++ драйвера, и программирование контроллеров (повышение производительности ПК только усугубляет положение C++).

Твоими бы устами

SS>Тут спор не в синтаксисе языков а в уровне абстракции.

Да, только уровень абстракции — человеческая прерогатива. Язык — это просто инструмент. Более или менее удобный. Который тем или иным образом влияет на пользователя. Об том и все эти споры.

По аналогии с филологической лингвистикой (извини за тавтологию), по отношению к программистской лингвистике можно, ИМХО, постулировать, что язык определяет набор абстракций, которыми человек оперирует при удовлетворении своих интеллектуальных потребностей. Есть только одна закавыка — набор абстракций должен быть инструментом попрождения работающей системы. Вот тебе и связка и переход между "уровнем абстракции человека" и "уровнем абстракции от аппаратуры".

SS>Я тоже с ностальгией вспоминаю времена, когда сидя в DOC на Borland C++ 2.0, поковыряв программу в TurboProfiler, можно было сделать умное выражение лица, написать asm{..}, поднапрячь интелект, решив сложную комбинаторную задачу, по хитрому соптимизировать какую нибудь сортировку,распихать по регистрам, ... и с чувством глубокого удовлетворения наблюдать как прога стала "летать". Теперь такой уровень ни кому не нужен.

SS>Скоро станет не нужно и то что делалось на C++ в последние 5 лет.Возможности повторного использования кода у такого подхода очень слабые. Может это и интересно писать всякие эффективные хитрые алгоритмы сортировок, склеивания копирования строк, и.т.д., но они уже написаны, зачем каждый раз делать одно и тоже?. По крайней мере этим бубут заниматься очень не многие.

Интересно, рефлексия в форумах наверное никогда не прекратится.

Не, ребята, я больше в мыльных операх не участвую.

SS>А для более высокого уровня C++ не приспособлен.

А это очень похоже на формулу аутотренинга. Повторять утром и вечером!

Чтобы не подумалось иначе.

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

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

Вот сам и читай. Найдешь... кинь ссылочку. А так нечего стрелки переводить.

AVK>Да, тут в отличие от мн смысл есть. И вроде бы им там не особо напрягаться придется, ничего сложного нет.

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

VD>>3. Открыть как можно больше кода. На худой конец поправить Анакрину.

AVK>

VD>>Ставлю 10 пива,
AVK>10 чего? Кружек, бутылок, литров, баклажек, бочек?

Ящиков естественно.

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

IP>- Во первых писать что-то на шарпе для людей работающих не под XP/2000 (системные утилитки полезные например) нереально, потому что НИКОГО не заставишь себе на машину поставить CLR ради мелкой программы какой-нибудь — т.е. несмотря на рантаймы Backward compatibility распространяется только на "пузатых" клиентов (которые деньги заплатили и которым продукт навязать можно

)

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

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

ГВ>>А к чему фраза: "умеющее работать в глобальной сети"? Какая разница для приложения — глобальная сеть или локальная? Это вообще с точки зрения прикладной логики должно быть глубоко фиолетово, поскольку это — сугубо компьютерная, а не прикладная специфика. Сие есть забота сетевых драйверов и прочих коммуникационных прослоек (в т.ч. — ORB, DCOM и т.п.).
ГВ>>>>Так вот, ИМХО, что Web-интерфейсы, что Windows-UI+что-то-там сеть — всё едино с точки зрения приложения, поскольку прикладная логика от этого не должна изменяться (Если меняется, то это — бардак)

SS>Вот именно, интерфейс это мелочь, главное прикладная логика, которая не должна сильно меняться от типа приложения (настольное, WEB,..).
SS>А теперь вопрос на засыпку: Допустим ты написал на супер универсальном языке C++, очень универсальные классы с прикладной логикой. Каким образом ты собираешься запихнуть свои труды в процесс WEB-сервера (или другого сервера, или если другой программе захочется подергать за твое хозяйство).
SS>Единственное более менее вменяемое решение для этого — COM,DCOM.
SS>Во что превращается прикладная логика когда кней привинчивают COM,ATL? Это довольно печальное зрелище.
SS>Вот мне бы это и хотелось услышать от противников .NET,С#,Java примерно такую фразу:
SS>"реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET"

А в apache дотнетовские классы/сборки/чтоунихтам запихиваются?

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

SS>

AVK>>>>>Ну я то тебе как раз попробовать что нибуть написать для дотнета советовал.
ГВ>>>>Да вот я и думаю — стоит на него тратить время сейчас или подождать выхода версии 6.0 ?

Я не Нострадамус, но ежели 6 версия .Net таки будет, то скорее всего она окажется последней

Так что дожидаться ее не стоит

SS>Ой не знаю дождешся ли 6 версии .NET программируя на C++. Я имею ввиду доживет ли C++ до 6 версии .NET ????
SS>В последние годы ява заметно потеснила C++, теперь M.soft его добил. От силы 4-5 лет и все, останутся для C++ драйвера, и программирование контроллеров (повышение производительности ПК только усугубляет положение C++).

Ну, это уж перебор. Повышение производительности ПК обычно сопровождается повышением аппетитов пользователей. На долю С++ останутся, как минимум: движки баз данных, игрушки, графика — и 2, и 3D, статистика всякая, Data/Text mining, да и тот же пользовательский интерфейс, как это ни странно звучит. Например, чтоб не очень убого расположить подписи на круговой (aka "торт") диаграмме, весьма дофига считать приходится (причем, в доли секунды желательно уложиться). Я уж не говорю про визуализацию графов (да и любых больших объемов данных вообще). Или вот как то пришлось делать — есть набор полей в базе данных, есть набор полей в проекте (до нескольких сотен). Называются они похоже, но не идентично. Их надо сопоставить друг другу. Шоб пользователю ручками все сотни не мапить, желательно похожие (не одинаковые) сопоставить автоматом — причем быстро, юзер долго ждать не любит. Прикинь потребную вычислительную мощь. Жаба/нет тут не катят

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

SS>Тут спор не в синтаксисе языков а в уровне абстракции.
SS>Я тоже с ностальгией вспоминаю времена, когда сидя в DOC на Borland C++ 2.0, поковыряв программу в TurboProfiler, можно было сделать умное выражение лица, написать asm{..}, поднапрячь интелект, решив сложную комбинаторную задачу, по хитрому соптимизировать какую нибудь сортировку,распихать по регистрам, ... и с чувством глубокого удовлетворения наблюдать как прога стала "летать". Теперь такой уровень ни кому не нужен.

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

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

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

SS> Может это и интересно писать всякие эффективные хитрые алгоритмы сортировок, склеивания копирования строк, и.т.д., но они уже написаны, зачем каждый раз делать одно и тоже?.

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

А если все уже написано до нас, найди мне, плиз, реализацию tabu search для point feature labeling problem, на любом языке, можно хоть на шарпе

SS>По крайней мере этим бубут заниматься очень не многие.

Уже сейчас очень многие только тем и занимаются, что 1С конфигурируют. Но я к ним не хочу

SS>А для более высокого уровня C++ не приспособлен.

Ню-ню.

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

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

SS>>Во что превращается прикладная логика когда кней привинчивают COM,ATL? Это довольно печальное зрелище.
ГВ>В прикладную логику с подключённой "толстой" интерфейсной прослойкой. То есть, в то, во что она и должна превратиться в этом случае.

Вот вот. Если эта толстая прослойка практически одинаковая во многих задачах, ее надо делать прозрачной, чтобы не тратить время на однообразную механическую работу.
Тебе нравится писать такие однообразные прослойки? Или эту работу у вас выполняют тупые кодеры, зазубрившие наизусть COM, ATL.

ГВ>Это от объёма задачи зависит. Чем она больше — тем важнее унификация внутренней структуры и глубина проработки абстракций. Тем адекватнее там C++.

Мы расходимся во мнении, что абстракции проще прорабатывать на более высокоуровневых языках.
Либо ты считаешь C# языком с ограниченными возможностями, наподобии VB6. Я другого мнения.

ГВ>>>>>Да вот я и думаю — стоит на него тратить время сейчас или подождать выхода версии 6.0 ?

SS>>Ой не знаю дождешся ли 6 версии .NET программируя на C++. Я имею ввиду доживет ли C++ до 6 версии .NET ????
ГВ>Да C++-то доживёт. А вот доживёт ли .NET не мутировав во что-то ещё "очень новое" — абсолютно не уверен.

Скорей бы придумали, что нибудь еще более крутое чем .NET, из последних сил цеплятся за .NET не буду.

SS>>А для более высокого уровня C++ не приспособлен.
ГВ>А это очень похоже на формулу аутотренинга. Повторять утром и вечером!

Чтобы не подумалось иначе.

Ну ты не путай мое мнение о C++, с мнением Java-программистов о C#/.NET — это совсем из другой области.
Я же не всегда так думал, было время долго фанател от C++, и было там от чего фанатеть. Могу даже сертификаты Microsoft показать по Visual С++.

Хотя в этих экзаменах языка C++ даже и нету

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

Если ты отвергаешь технологии .NET/C#,Java из-за того что пугают мрачные картины будущего, описанные в этом фантастическом расказе в стиле кибер-панк:
http://www.rsdn.ru/forum/Message.aspx?mid=95594&only=1
Где описано как интелектуально и морально разложившиеся программисты, опухшие отупевшие и окосевшие от скуки, создают крутые ERP и прочие системы перетаскивая мышкой на формах разные компонетты с места на место. Раскрашивают их в разные цвета и отвечают на вопросы визардов.

Это напрасно. Более высокоуровневая это наоборот более интелектуальная работа — то что не может сделать компьютер.
VB6 и всякие нынешние Case системы и 4GL языки — это не полноценые универсальные системы, а просто готовые шаблоны узкоспециализированных решений, поддающиеся настройке.
.NET сюда относить не стоит.

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

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

ГВ>Это от объёма задачи зависит. Чем она больше — тем важнее унификация внутренней структуры и глубина проработки абстракций. Тем адекватнее там C++.

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

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

S>Ну, это уж перебор. Повышение производительности ПК обычно сопровождается повышением аппетитов пользователей. На долю С++ останутся, как минимум: движки баз данных, игрушки, графика — и 2, и 3D, статистика всякая, Data/Text mining, да и тот же пользовательский интерфейс, как это ни странно звучит. Например, чтоб не очень убого расположить подписи на круговой (aka "торт") диаграмме, весьма дофига считать приходится (причем, в доли секунды желательно уложиться). Я уж не говорю про визуализацию графов (да и любых больших объемов данных вообще). Или вот как то пришлось делать — есть набор полей в базе данных, есть набор полей в проекте (до нескольких сотен). Называются они похоже, но не идентично. Их надо сопоставить друг другу. Шоб пользователю ручками все сотни не мапить, желательно похожие (не одинаковые) сопоставить автоматом — причем быстро, юзер долго ждать не любит. Прикинь потребную вычислительную мощь. Жаба/нет тут не катят

Ну, это уж перебор. Повышение производительности ПК обычно сопровождается повышением аппетитов пользователей. На долю С останутся, как минимум: движки баз данных, игрушки, графика — и 1, и 2D, статистика всякая, Data/Text mining, да и тот же пользовательский интерфейс, как это ни странно звучит. Например, чтоб не очень убого расположить подписи на круговой (aka "торт") диаграмме, весьма дофига считать приходится (причем, в доли секунды желательно уложиться). Я уж не говорю про визуализацию графов (да и любых больших объемов данных вообще). Или вот как то пришлось делать — есть набор полей в базе данных, есть набор полей в проекте (до нескольких сотен). Называются они похоже, но не идентично. Их надо сопоставить друг другу. Шоб пользователю ручками все сотни не мапить, желательно похожие (не одинаковые) сопоставить автоматом — причем быстро, юзер долго ждать не любит. Прикинь потребную вычислительную мощь. C++ тут не катит

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

Это я припоминаю подобные разговоры 10-летней давности

Остальное поскипано.

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

Да нет у дотнета тех недостатков о которых вы говорите, просто нету. Всё это высосано из пальца и базируется на устаревшем представлении о Java тех времён, когда она работала только в режиме интерпретации. CLR ни чуть не медленнее обычного нативного кода, почитайте Шустриков в конце концов. Контроль ресурсов говорите? А разве в серьёзных игрушках используется стандартный C++ хип? Сомневаюсь, наверняка там своя подсистема управления памятью. Что-нибудь подобное придумают и для C#. Т.е всё это приходящее.

Что же касается полей в базе данных... Был проект написанный на C++ и занимающийся обработкой данных. На один двух-гигабайтный файл уходило до 57 часов. Всё это хозяйство было переписано на C#, время сократилось до 40 минут. В чём дело, спросите вы? Правильно, в правильном дизайне и применении вспомогательных технологий, никак не связанных с самим языком.

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

IT>Господа, сколько уже можно вас призывать и уговаривать. Если вы хотите рассуждать о предмете, то необходимо с ним хотя бы ознакомится.

В процессе...

IT>Да нет у дотнета тех недостатков о которых вы говорите, просто нету. Всё это высосано из пальца и базируется на устаревшем представлении о Java тех времён, когда она работала только в режиме интерпретации.

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

IT>CLR ни чуть не медленнее обычного нативного кода, почитайте Шустриков в конце концов.

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

IT>Контроль ресурсов говорите?

А какие ресурсы, кроме памяти, может автоматически контролировать .Net?

IT>А разве в серьёзных игрушках используется стандартный C++ хип?

Если серьезной игрушкой считать Quake II, так там даже и плюсами не пахнет. Голимый "пуре Це"

И при чем тут, собственно, хип? Быстродействие не только от него зависит. C++ кардинально отличается от нетовских языков тем, что в C++ GC или иной способ управления памятью можно реализовать с куда меньшим геморроем, чем в нетовских языках организовать собственное управление памятью. Да и никто не заставляет в C++ всегда пользоваться евойным хипом, при необходимости можно и системные функции подергать. Тормозил у меня, например, std::stringstream — так я написал свой стримбуфер со своим аллокатором, стало просто летать. Причем, что характерно, если мне этот код портировать вдруг понадобится, я просто поменяю пару дефайнов и на отличных от винды платформах будет работать все тот же std::stringstream — медленно, но будет. Пока нативный аллокатор не напишу

В нете такое практически нереализуемо.

IT>Сомневаюсь, наверняка там своя подсистема управления памятью. Что-нибудь подобное придумают и для C#. Т.е всё это приходящее.

Вот именно, приходящее и уходящее. Когда еще придумают то. А работать сейчас надо.

IT>Что же касается полей в базе данных... Был проект написанный на C++ и занимающийся обработкой данных. На один двух-гигабайтный файл уходило до 57 часов. Всё это хозяйство было переписано на C#, время сократилось до 40 минут. В чём дело, спросите вы?

Дело тут может быть только в том, что программист(ы), писавшие эту С++ программу, плохо владели инструментом. Им и правда надо на .Net сваливать.

IT>Правильно, в правильном дизайне и применении вспомогательных технологий, никак не связанных с самим языком.

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

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

IT>>Господа, сколько уже можно вас призывать и уговаривать. Если вы хотите рассуждать о предмете, то необходимо с ним хотя бы ознакомится.

S>В процессе...

Во-во, давай, а то уже чесслово надоело одно и тоже доказывать.

IT>>Да нет у дотнета тех недостатков о которых вы говорите, просто нету. Всё это высосано из пальца и базируется на устаревшем представлении о Java тех времён, когда она работала только в режиме интерпретации.

S>Дак и у С++ нет тех недостатков, о которых вы говорите. О тех, которые у него на самом деле есть и жить мешают, все почему-то молчат.

Разве кто-то говорит о недостатках? Речь идёт об отсутствии достоинств, которые его выделяли 10 лет назад среди других языков и которыми уже сейчас уже никого не удивишь. Хотя впрочем то, что язык тормознулся в своём развитии тоже можно считать недостатком.

IT>>CLR ни чуть не медленнее обычного нативного кода, почитайте Шустриков в конце концов.

S>Дык это смотря как тестировать. Я надеюсь, ты не станешь утверждать, что виртуальные функции вызываются быстрее обычных? Аналогия понятна? Блин, "антишустрика" написать, что ли...

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

IT>>Контроль ресурсов говорите?

S>А какие ресурсы, кроме памяти, может автоматически контролировать .Net?

Только память. А разве я утверждал обратное?

IT>>А разве в серьёзных игрушках используется стандартный C++ хип?

S>Если серьезной игрушкой считать Quake II, так там даже и плюсами не пахнет. Голимый "пуре Це"

И вся графика ручками написана без всяких DirectX. Или я не прав? Может и не прав, но вот в Doom точно без DirectX обошлись. И что, ты станешь сейчас в неё играть когда уже есть Tournament?

S>И при чем тут, собственно, хип? Быстродействие не только от него зависит. C++ кардинально отличается от нетовских языков тем, что в C++ GC или иной способ управления памятью можно реализовать с куда меньшим геморроем, чем в нетовских языках организовать собственное управление памятью. Да и никто не заставляет в C++ всегда пользоваться евойным хипом, при необходимости можно и системные функции подергать. Тормозил у меня, например, std::stringstream — так я написал свой стримбуфер со своим аллокатором, стало просто летать. Причем, что характерно, если мне этот код портировать вдруг понадобится, я просто поменяю пару дефайнов и на отличных от винды платформах будет работать все тот же std::stringstream — медленно, но будет. Пока нативный аллокатор не напишу

S>В нете такое практически нереализуемо.

Ну вот опять

Я надеюсь ты знаешь кое что об интерфейсах. В дотнете я могу написать свой форматер и передавать данные между стандартными объектами по своему доморощенносму протоколу и всё будет летать. А вот на C++ вместе с COM'ом такого не сделаешь.

Давай не будем приводить в качестве аргумента частные решения. Как я уже говорил всё зависит от дизайна и прямости рук. У меня вообще может возникнуть вполне законный вопрос — а нафига тебе понадобился стримбуфер, неужели нельзя было обойтись без него

IT>>Сомневаюсь, наверняка там своя подсистема управления памятью. Что-нибудь подобное придумают и для C#. Т.е всё это приходящее.

S>Вот именно, приходящее и уходящее. Когда еще придумают то. А работать сейчас надо.

Если ты занимаешься игрушками, то используй C++ и "голимый Це", никто тебя в .NET не тянет. Твоё время пока не пришло

IT>>Что же касается полей в базе данных... Был проект написанный на C++ и занимающийся обработкой данных. На один двух-гигабайтный файл уходило до 57 часов. Всё это хозяйство было переписано на C#, время сократилось до 40 минут. В чём дело, спросите вы?

S>Дело тут может быть только в том, что программист(ы), писавшие эту С++ программу, плохо владели инструментом. Им и правда надо на .Net сваливать.

Опять ты не понял. Ни программисты, ни C++, ни C# тут ни при чём. Парсер был перенесён один в один из C++ в C#. Разница была лишь в методе вставки данных в базу данных. Во втором случае использовался BULK INSERT, который сам по себе работает в десятки раз быстрее.

IT>>Правильно, в правильном дизайне и применении вспомогательных технологий, никак не связанных с самим языком.

S>Во-во, сравнивают плохой сишный код с хорошим нетовским и говорят, что второе — быстрее. Так кто ж спорит, я вполне могу написать программу на С++, которая будет работать медленне бэйсиковского аналога, мною же написанного.

Да ладно

Всё это мы уже слышали про крутых C++ программеров и даже сами так кричали по всем фидошным эхам в своё время. Но я надеюсь ты не думаешь, что если кто-то был хорошим программером только потому что он писал на C++, и вдруг сразу стал плохим так как начал писать на C#

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	09.09.02 07:43
Оценка:

	От:	Mink
	Дата:	09.09.02 08:04
	Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	09.09.02 08:18
Оценка:

	От:	Mink
	Дата:	09.09.02 08:52
	Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	09.09.02 14:27
Оценка:

От:	VladD2	www.nemerle.org
Дата:	09.09.02 23:01
Оценка:

От:	Yampolski_Nikita	http://nikitay.pisem.net
Дата:	10.09.02 16:14
Оценка: