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

AVK>>ИМХО дело не в высокости уровня, дело в подходе к проектированию.

E>А расшифровать свое ИМХО можешь?

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

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

E>Изобретали, я бы сказал. Многие библиотеки (например, Qt, wxWidgets, ACE) начали развиваться еще до появления данных классов и до их стандартизации. Сейчас, к тому же, идет процесс добавления поддержки стандартных классов во многие старые библиотеки. В частности, Qt нормально дружит с std::string.

таких пока мало. не думаю, что они сейчас потянут хотя бы на 1% от общего количества библиотек.

E>Если же речь идет об исключениях, то есть std::exception, а все, что std::exception не поддерживает -- см.п.1.

а еще есть коды возврата и установка глобального кода ошибки

E>В распространенных?

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

E>auto_ptr в контейнера -- это элементарное не знание языка.

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

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

E>* Вычислительные задачи. Прогнозирование погоды, моделирование аэродинамики, термодинамики, имитационное моделирование, компьютерная графика...

Один умный человек, а именно Кирилл Фаенов, главный по HPC в MS, рассказывал о том что последнее время в этой области все чаще используется Java, потому что очень часто задачи на вычисление разовые и время разработки, по сути, является частью вычислительного процесса.

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

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

A>>Меня уже достали твои общие слова. Ты отрицаешь наличие высокоуровневых возможностей в C++?

Д>А меня достал ты со своей уверенностю в том, что ты здесь лучше всех знаешь С++.

Да, я вижу поголовное плохое знание С++. Это большая проблема.

Д>Там нет:
Д>1. Стандарта на массивы и строковый тип. std::vector и std::string на эту роль не подходят, потому что все равно авторы каждой библиотеки изобретают собственные велосипеды.

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

Д>2. Стандарта на политику обработки ошибок

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

Д>3. Нормальной возможности использовать функциональные типы (заменители на килобайтах шаблонов и макросов — не считаются)

Это камень предкновения? Программируй на функциональном языке.

Д>4. Замыканий

Функторы.

Д>5. Уверенности в том, что безобидный на вид код не окажется злостным UB

Не замечено. Давай ты приведёшь пример well-formed C++ кода, использующего высокоуровневые абстракции, в котором тебя ждут упомянутые тобой проблемы.

Д>Там есть:
Д>1. Хреновая поддержка стандарта в распространенных компиляторах

К языку не относится. Не нужно путать язык и его реализации. К тому же в распостранённых компиляторах поддержка стандарта уже oчень хорошая.

Д>2. Необходимость писать килограммы оберток каждый раз, когда тебе нужно использовать чужую библиотеку (см п.1 и п.2)

Проблемы библиотек. Объясни мне, как херовые сторонние библиотеки вдруг стали проблемой языка?

Д>3. Заботливо разложенные на каждом шагу грабли, в качестве ярких примеров — vector<bool>, auto_ptr в котейнерах, и прочие радости.

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

vector<bool> настолько искуственный пример, что если тебе не сказали о его проблемах, ты бы даже и не подозревал.

---
Все твои "аргументы" даже и на йоту не ближе к тому, чтобы показать, что на С++ нельзя программировать на высоком уровне абстракции.

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

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

A>>Ну, ёлки палки!

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

Что меня всегда удивляет в выступлениях (большинства) защитников .Net-языков — это упорство, с которым вы пытаетесь обобщить свой опыт на всех
Типичный пример: раз у тебя нет печального опыта работы с C++ — значит, ты еще маленький; подрастёшь — всё поймёшь

Человек, высказывающий предположение, что кто-то может быть более продуктивен, программируя на C++, изначально рассматривается как еретик, подлежащий обращению в "Истинную Веру". Печально.

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

A>Это камень предкновения? Программируй на функциональном языке.

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

A>Все твои "аргументы" даже и на йоту не ближе к тому, чтобы показать, что на С++ нельзя программировать на высоком уровне абстракции.

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

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

VD>>Боюсь, что это им может оказаться не позубам. Хотя вопрос сожный. Тут без серьезного анализа ничего толком сказать нельзя.

Д>я видел статью с готовым кодом, в которой прикручиваются мультиметоды к Смоллтоку.

Если именно мультиметоды, а не двойную диспетчерезацию, то без изменения ВМ это почти невозможно. Под "невозможно" следует понимать множество ручной работы с неясным результатом, и врядли приемлимой скоростью.
Замечу, что так как ST — язык алгоритмически полный, то множественную диспетчеризацию реализовать можно, но "сверху" языка, а так чтобы оно было неотличимо по использованию от классических методов — врядли.

Д>Вероятно, в Немерле можно сделать по тому же принципу — макросы рулят . Жаль только, сейчас нет времени попробовать.

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

C>6. Кросс-платформенные приложения (не надо про Mono).
А ты с кем сравниваешь? Случайно не с Явой? Трудно говорить о кросс-платформенности С++, если даже компиляторы друг с другом не всегда кросс.
Так что, если говорить о кросс-платформенности, то кросс-платформенность с помощью Явы достигается меньшей кровью.

GlebZ wrote:
> C>6. Кросс-платформенные приложения (не надо про Mono).
> А ты с кем сравниваешь? Случайно не с Явой? Трудно говорить о
> кросс-платформенности С++, если даже компиляторы друг с другом не всегда
> кросс.
При использовании некого subset'а функциональности — вполне себе портируемо.

> Так что, если говорить о кросс-платформенности, то кросс-платформенность
> с помощью Явы достигается меньшей кровью.
Ага, программы на Java одинаково плохо работают везде

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

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

C>>Да ни в чем, в общем-то. Уже 5 лет прошло, а софта на С# не так уж и
C>>много для следующей революционной технологии.
VG>В США востребованы .NET разработчики лично мне это говорит, что эти приложения очень активно пишутся.
VG>Назовите приложения на Smalltalk? А их много, и не только реализации языка.
VG>Назовите приложения использующие ООСУБД (не постреляционные), а их в мире довольно много.
VG>Исторически, на территории бывшего СССР сложилась некоторая монополия C++, которая способствовала росту касты "плюсеров", занимающихся цитированием Языкового Стандарта C++, толкованием кода и изголяющимся в реализации различных концепций/средств на языке, который эти концепции и средства либо слабо поддерживает, либо не поддерживает вообще.

Хочется от себя добавить, что постсоветское пространство это одна из монополий дельфи (у нас он распространён гораздо больше чем на западе), почему же мы не видим противостояние его и шарпа?

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

Д>>А меня достал ты со своей уверенностю в том, что ты здесь лучше всех знаешь С++.
A>Да, я вижу поголовное плохое знание С++. Это большая проблема.
Вот это точно. Я уже больше 10 лет на нем программирую, и могу точно сделать вывод. Я не знаю С++.

Есть один пункт — хреновая поддержка RTTI. Отсутсвие нормального reflection ведет к огромнейшим извращениям в том, что с ним связано.

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

>> C>6. Кросс-платформенные приложения (не надо про Mono).
>> А ты с кем сравниваешь? Случайно не с Явой? Трудно говорить о
>> кросс-платформенности С++, если даже компиляторы друг с другом не всегда
>> кросс.
C>При использовании некого subset'а функциональности — вполне себе портируемо.
Ага, проблема существует. В С++ присутсвует огромное количество функционала, пользоваться которыми просто опасно. И лично я не уверен, что я знаю его весь. И уверен, что большинство его не знает.

>> Так что, если говорить о кросс-платформенности, то кросс-платформенность
>> с помощью Явы достигается меньшей кровью.
C>Ага, программы на Java одинаково плохо работают везде
Вопрос эффективности, и что под ним понимать — это уже вопрос другого флейма. Уверен что многие с тобой не согласятся.

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

Д>>4. Замыканий

A>Функторы.

Бред. Вот пара примеров навскидку:

Придуманный:

def MakeInvertedPredicate(p) { fun(x) { !p(x) } }

Как это реализовать на С++? Знаю что можно, да думать лень, когда уже повсюду реализованы нормальные средства.

Реальный:

def Sort(item : int, reverse : bool) : void
{
    def pred(av, bv) : bool
    {
        def (a, b) = if (reverse) (bv, av) else (av, bv);
        some_natural_order_string_compare(a[item], b[item]) < 0
    }
    some_standart_sort(m_data.begin(), m_data.end(), pred)
}

А как это делается на С++? Обрати внимание на необходимость вручную передать члены класса, скопировать в конструкторе...

    void Sort(int item, bool reverse)
    {
        struct Pred
        {
            int m_nItem;
            bool m_reverse;
            Pred(int nItem, bool rev) : m_nItem(nItem), m_reverse(rev) {}
            bool operator()(std::vector<CString> const& av, std::vector<CString> const& bv)
            {
                CString const& a = (m_reverse ? bv : av)[m_nItem];
                CString const& b = (m_reverse ? av : bv)[m_nItem];
                return strnatcasecmp(a, b) < 0;
            }
        };
        std::sort(m_data.begin(), m_data.end(), Pred(item, reverse));
    }

Надеюсь не надо пояснять, что будет, если таких передаваемых параметров будет 8-10? А что если в их числе должны будут быть другие предикаты (которые могут быть статическими функциями или членами классов), которым тоже надо что-то передать?

Ты можешь сказать, что у тебя таких ситуаций не было. А почему не было? Потому что тебе не приходило в голову, что так можно, исключительно из-за того, что на С++ это делать трудно и результат получается непонятным. Вот тебе косвенный показатель "высокости уровня": на каждом "уровне" свои проблемы. Например, трудно представить программиста на Си, перетряхивающего большую иерархию классов

Наличие замыканий — это дополнительный уровень абстракции. Недавно всплывали числа Черча — чем не абстракция? На С++ эта абстракция недоступна.

Д>>5. Уверенности в том, что безобидный на вид код не окажется злостным UB
A>Не замечено. Давай ты приведёшь пример well-formed C++ кода, использующего высокоуровневые абстракции, в котором тебя ждут упомянутые тобой проблемы.

Не раз в форуме C++ были темы с безобидной функцией, в которой находили до десятка потенциальных проблем. Проблема как раз в выделенном — трудно сразу сказать, является код ill-formed, или это well-formed с UB, или всё правильно. К примеру:

struct A
{
  T* x, y;
  A() : x (new T), y (new T) {}
};

Д>>2. Необходимость писать килограммы оберток каждый раз, когда тебе нужно использовать чужую библиотеку (см п.1 и п.2)
A>Проблемы библиотек. Объясни мне, как херовые сторонние библиотеки вдруг стали проблемой языка?

Всегда были. Я тебе продемонстрировал Такие мелочи, когда из-за недостатка фич в языке неожиданно приходится писать какую-то муть, в совокупности заставляют отказаться от некоторых выгодных стилей программирования. Например, мне бы хотелось услышать, как ты объяснишь новичку в С++ (умеющему создать вектор чисел и отсортировать) приведенную реализацию Sort, зачем там ещё класс, почему так? Или может приведёшь более понятную реализацию (отсортировать два двухмерных массива (jagged) по заданному номеру столбца, опционально с инверсией)?

Д>>3. Заботливо разложенные на каждом шагу грабли, в качестве ярких примеров — vector<bool>, auto_ptr в котейнерах, и прочие радости.
A>Эти грабли хорошо изветсны и никакой опасности не представляют.



Про массив auto_ptr все знают. Везде написано. А вот про это — не везде:

void foo(auto_ptr<T> param)
{
}

A>Все твои "аргументы" даже и на йоту не ближе к тому, чтобы показать, что на С++ нельзя программировать на высоком уровне абстракции.

Насколько высоком? Более высоком, чем на Си? Да. На не менее высоком, чем позволяет любой другой существующий язык? Увы, нет.

Факт в том, что в других языках есть нужные и полезные возможности, которых в С++ нет. Следующий стандарт готовят через несколько лет и там их тоже нет. Это возможности вроде замыканий или макросов, которые средствами языка, без привлечения дополнительного препроцессора, реализовать в принципе никак. В редких случаях возможны извраты (благодаря которым переменные приходится объявлять как DECLARE(int, x) и т.п.), дающие некое подобие.

Совершенно не понятно, зачем Microsoft было затевать эту разработку технологии .NET, Новых языков, сред программированию. С точки зрения технической пользы, понятно. что финансовую выгоду они с этого получат — факт.
1. Однако, если кто-то забыл, то и C и С++ задумывались как своеобразные средства переноса программ с одного компьютера на другой. Достаточно было написать новый компилятор для программы и она запускалась на требуемой машине. И это кажется более логичным, чем таскать виртуальную машину или какую-то среду исполнения на каждой машине и даже каждой ОС, для которой хотели бы запуститься. Чувствуете разницу — в одном случае мы имеем дело с типом машин, а в случае подхода C# с каждой машиной в отдельности.
2. Все, что реализовано в .NET можно было смело реализовывать и в Visual C++ 8.0. Что мешало? При этом С++ является хорошо изученным + куча библиотек. Почему бы не расширять/урезать этот язык? ... Маркетинг?

И еще: в заголовке опечатка.

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

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

E>1. Однако, если кто-то забыл, то и C и С++ задумывались как своеобразные средства переноса программ с одного компьютера на другой. Достаточно было написать новый компилятор для программы и она запускалась на требуемой машине.
Какая наивность! Такую программу, которая заустится на любой требуемой машине, еще поискать.
E> И это кажется более логичным, чем таскать виртуальную машину или какую-то среду исполнения на каждой машине и даже каждой ОС, для которой хотели бы запуститься. Чувствуете разницу — в одном случае мы имеем дело с типом машин, а в случае подхода C# с каждой машиной в отдельности.
E>2. Все, что реализовано в .NET можно было смело реализовывать и в Visual C++ 8.0. Что мешало? При этом С++ является хорошо изученным + куча библиотек. Почему бы не расширять/урезать этот язык? ... Маркетинг?
Это как например? Можно услышать некоторые комментарии, как можно было бы реализовать сборку мусора и reflection вместе с reflection.emit в рамках C++ 8.0?
E> И еще: в заголовке опечатка.
Неа, нету.

З.Ы. Прежде чем делать столь уверенные заявления, не мешает немножко поближе познакомиться с предметом. Хотя бы с одним из вынесенных в заголовок темы.

Когда-то давно еще во время появления C++, помнится, был примерно аналогичный спор аля Asm vs C++. Потом было C++ vs Java (наиболее близко к данной теме, если подумать).

У меня де жа вю или эта тема неисчерпаема? Удивляюсь только как очевидно опытные программисты типа VladD2 и WolfHound позволяют себя втянуть в подобный спор.


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


P.S. По поводу "серьезных проектов"... вот у нас проектик на 80 с гаком метров C# кода живет и здравствует... Страшно подумать какой монстр получился бы, если бы писали его на C++.

Здравствуйте, Sinclair, Вы писали:
Эмоциональный выпад, однако.

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

E>>Совершенно не понятно, зачем Microsoft было затевать эту разработку технологии .NET, Новых языков, сред программированию. С точки зрения технической пользы, понятно. что финансовую выгоду они с этого получат — факт.
S>
E>>1. Однако, если кто-то забыл, то и C и С++ задумывались как своеобразные средства переноса программ с одного компьютера на другой. Достаточно было написать новый компилятор для программы и она запускалась на требуемой машине.
S> Какая наивность! Такую программу, которая заустится на любой требуемой машине, еще поискать.
E>> И это кажется более логичным, чем таскать виртуальную машину или какую-то среду исполнения на каждой машине и даже каждой ОС, для которой хотели бы запуститься. Чувствуете разницу — в одном случае мы имеем дело с типом машин, а в случае подхода C# с каждой машиной в отдельности.
E>>2. Все, что реализовано в .NET можно было смело реализовывать и в Visual C++ 8.0. Что мешало? При этом С++ является хорошо изученным + куча библиотек. Почему бы не расширять/урезать этот язык? ... Маркетинг?
S> Это как например? Можно услышать некоторые комментарии, как можно было бы реализовать сборку мусора и reflection вместе с reflection.emit в рамках C++ 8.0?

1. Уборка мусора.
Про сборку мусора можешь почитать в классической книге Дж. Коплиена "Программирование на С++" за 1992 год(!),
страница 333 9.5. Уборка мусора.
2. Рефлексия. Этот вопрос уже неоднократно обсуждался на форуме С/С++ вот ссылка на библиотеку, которая позволяет реализовать рефлексию для С++ в его нынешнем состоянии: rsdn

Автор: Batiskaf
Дата: 30.04.04

. Вобщем не вижу сложностей с реализацией рефлексии на С++ такой карпорацией, как MS.
3. Emit Собственно есть рефлексия — есть Emit.
И последнее, надеюсь с твоей стороны есть понимание, что я имел ввиду потенциальный C++ 8.0, когда говорил о нем, с ключевыми словами, с типами классов — типа рефлексируемый и пр., не нынешний?

E>> И еще: в заголовке опечатка.
S>Неа, нету.
И всетаки есть. На моё сообщение не смотри, смотри выше.

S>З.Ы. Прежде чем делать столь уверенные заявления, не мешает немножко поближе познакомиться с предметом. Хотя бы с одним из вынесенных в заголовок темы.
Многие программисты — аутентичные интраверты. Они очень стеснительны и неуверены в себе, ни с девушками, ни в обычной беседе. Смелые заявления — это не для них. У меня такое ощущение, что это и про тебя. Я прав?

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

kuj>Когда-то давно еще во время появления C++, помнится, был примерно аналогичный спор аля Asm vs C++. Потом было C++ vs Java (наиболее близко к данной теме, если подумать).

Как все просто. И думать не надо. Asm->C->C++->Java->C#. Правильно я понимаю. Вот только напишите мне, пожалуйста, что именно было привнесенно на каждом из этапов нового в программирование. На Jav'е у меня все заканчивается.

kuj>У меня де жа вю или эта тема неисчерпаема? Удивляюсь только как очевидно опытные программисты типа VladD2 и WolfHound позволяют себя втянуть в подобный спор.
Дык... А чем им еще делать?

kuj>Очевидным остается факт, что в программирование с каждым годом становится все более экстримальным — сроки сжимаются, а функционал требуют все богаче и удобнее.
Так на C# даже иконку в хидер Лист Контрола вынести без апи нельза о каком функционале идет речь?
C++ жив и будет жить еще долго — пока существуют ниши для него, но тенденции к переходу на все более высокоуровневые и богатые языки сохраняются.
kuj>Клиентов обычно не волнует как и на чем будет реализована нужная ему функциональность, а главное — сроки на выполнение и качество работы.
Сроки да — С# дает приимущество для большениства программистов, а вот качество под сомнением.

kuj>P.S. По поводу "серьезных проектов"... вот у нас проектик на 80 с гаком метров C# кода живет и здравствует... Страшно подумать какой монстр получился бы, если бы писали его на C++.
Могу с уверенностью сказать, даже не видев вашего проекта, что если создать аналогичный проект на С++ — клон то есть, то качество его исполнения будет гораздо выше. Сроки тоже несколько выше, но приемлемо.

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

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

kuj>У меня де жа вю или эта тема неисчерпаема? Удивляюсь только как очевидно опытные программисты типа VladD2 и WolfHound позволяют себя втянуть в подобный спор.
Если ты посмотришь на первое сообщение то увидишь что данная тема начиналась в другом форуме и в болие интересной ветке...
К томуже иногда хочется пофлеймить.

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

kuj>>У меня де жа вю или эта тема неисчерпаема? Удивляюсь только как очевидно опытные программисты типа VladD2 и WolfHound позволяют себя втянуть в подобный спор.
E>Дык... А чем им еще делать?
Ну например Кваку погонять... гораздо болие продуктивное занятие...

E>Так на C# даже иконку в хидер Лист Контрола вынести без апи нельза о каком функционале идет речь?
Ну если для тебя нету разницы между C# и кривущей библиотекой WinForms то разговор на этом можно закончить.

E>Сроки да — С# дает приимущество для большениства программистов, а вот качество под сомнением.
Аргументы? Только не говори что C# тормоз и памяти много жрет. Ни то ни другое не соответствует реальности если все делать прямыми руками.

E>Могу с уверенностью сказать, даже не видев вашего проекта, что если создать аналогичный проект на С++ — клон то есть, то качество его исполнения будет гораздо выше. Сроки тоже несколько выше, но приемлемо.
Я иногда жалею что на сайте запрещена падонковщина... А я модератор и мне надо быть образцом для подражания.
E>На мой взгляд С# в нынешнем его состоянии подходит для создания прототипов ПО, быстро накляпал полуработающию прогу, а потом, когда заказчику понравилось — написал нормальную рабочию версию на С++.
Ты можешь оставатся со своими иллюзиями столько сколько тебе хочется. Никому кроме тебя и твоих клиентов от этого хуже не станет. В прочем если клиенты умные то они от тебя сами уйдет.

ЗЫ Кстати про С++ мне расказывать не надо. Я сам о нем могу кому хочешь расказать. Причем могу расказать и про сильные стороны и про слабые.
ЗЗЫ У С++ не считая легаси кода есть своя ниша но она быстро сокращается.