VB обогнал C++

> бо всё это я уже где-то видел и слышал...

И до Марса докатилось? :)

Ну давайте тогда поговорим о ПЛ/1, алголе, модуле, обероне. Много ж есть хороших ЯП ;)

Вот, например, ПЛ/1 подходит для системного программирования: на нем написана ОС Мультикс. Тут недавно в толксах ссылка на сорцы была. А ведь ПЛ/1 похлеще С++ будет :)

> Сейчас уж не найду ту страничку, но цифра запомнилась: ~200'000 SLOC на LISP -- лисп-система с GUI, IDE'й и кучей инструментария. Ты бы лучше спросил, "Видели поддерживаемый софт на lisp, аналог которого на C++ хотя бы в пол милиона стрчоек?", тогда бы я ответил: "видели".

Ты на нее сам-то смотрел? Или только сылку видел?

примеры в студию

> обьясните, пожалуйста, в двух словах, почему С++ - быдлоязык, а С - нет...

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

1 1 Java 20.542% +0.14%

И точка.

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

>Си++ фактически это Си в который встроена поддержка абстракции данных.

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

1. С++ это мощнейший инструмент проектирования и программирования благодаря своему DDSL. Причем DDSL С++ Тьюринг-полный. Это доказано математически. 2. Благодаря DDSL достигается великолепная "абстрактизация" и генерализация кода. Ни в одном другом ЯП нет ничего подобного.

Если вы считаете, что STL это "костыль" - а(){ значит вы незнаете С++ и любое ваше высказывание по поводу C++ - беспочвенный пердёж }. Если вы незнаете STL и непонимаете зачем её использовать - а(); Если вы незнаете, что STL это часть языка и входит в ISO стандарт - а(); Если вы считаете, что потоки это лучшее что есть в С++ - ( а() + вы полный нуб ). забейте на потоки, эта позорно реализованая часть STL либо отомрет в ближайшее 10-20 лет, либо её исправят в конце концов. Если вы незнаете, что в мире нет ни одного UML инструмента, который бы мог адекватно отобразить связку template<AdaptorInterface> MyInterface; class MyImpl : public MyInterface<AdaptorImpl> , то вы просто незнаете С++ и концахйте его обсерать, особенно если вам непонятен смысл вышеприведенного примера.

> Если вы считаете, что STL это "костыль" - а(){ значит вы незнаете С++ и любое ваше высказывание по поводу C++ - беспочвенный пердёж }. Если вы незнаете STL и непонимаете зачем её использовать - а(); Если вы незнаете, что STL это часть языка и входит в ISO стандарт - а(); Если вы считаете, что потоки это лучшее что есть в С++ - ( а() + вы полный нуб ). забейте на потоки, эта позорно реализованая часть STL либо отомрет в ближайшее 10-20 лет, либо её исправят в конце концов. Если вы незнаете, что в мире нет ни одного UML инструмента, который бы мог адекватно отобразить связку template<AdaptorInterface> MyInterface; class MyImpl : public MyInterface<AdaptorImpl> , то вы просто незнаете С++ и концахйте его обсерать, особенно если вам непонятен смысл вышеприведенного примера.

Круто. За a() и фигурные скобки респект.

>>Си++ фактически это Си в который встроена поддержка абстракции данных.

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

http://www.research.att.com/~bs/C++.html Цитирую первую строчку: "C++ is a general purpose programming language with a bias towards systems programming that * is a better C..."

>С++ это мощнейший инструмент проектирования и программирования благодаря своему DDSL.

Начнем с того, что акроним DDSL ты придумал сам. А то о чем ты хотел тут написать называется C++ Templates.

>Причем DDSL С++ Тьюринг-полный. Это доказано математически.

Язык Тьюринга-Поста тоже Тьюринг-полный. Побежишь на нем писать? Кстати, математически тоже доказано, что в принципе невозможно написать полностью корректный парсер С++.

>2. Благодаря DDSL достигается великолепная "абстрактизация" и генерализация кода. Ни в одном другом ЯП нет ничего подобного.

Ты серьезно так думаешь?

Всем любителям крестов срочно компилировать:

template<int Depth, int A, typename B>
struct K17 {
static const int x =
K17 <Depth+1, 0, K17<Depth,A,B> >::x
+ K17 <Depth+1, 1, K17<Depth,A,B> >::x
+ K17 <Depth+1, 2, K17<Depth,A,B> >::x
+ K17 <Depth+1, 3, K17<Depth,A,B> >:x
+ K17 <Depth+1, 4, K17<Depth,A,B> >::x;
};
template <int A, typename B>
struct K17 <16,A,B> { static const int x = 1;
};
static const int z = K17 <0,0,int>::x;
int main(void) { }


О результатах компиляции расскажите дня через 2.

А любителям чистого Си:
#define ten(a) a a a a a a a a a a
#define C0 call();
#define C1 ten(C0)
#define C2 ten(C1)
#define C3 ten(C2)
#define C4 ten(C3)
#define C5 ten(C4)
#define C6 ten(C5)
int call(void) { return -1; }
void foo(void) { C6 }
int main() { foo(); return 0; }
Не забудте посмотреть на кол-во занятой оп

DDSL = DSL :) typo + copy-paste.

>"C++ is a general purpose programming language with a bias towards systems programming that * is a better C..."

Страуструп думал так, до того как Степанов и Александреску взялись за него (Страуструпа) всерьёз. В интерьвю к завершению работ по TR1, он признал свою ошибку и раскаялся. AT&T похоже нет.

>Кстати, математически тоже доказано, что в принципе невозможно написать полностью корректный парсер С++.

Врешь провокатор. Невозможно написать LALR парсер, однако GLR или LL с этой задачей справляются.

>Ты серьезно так думаешь?

Нахера мне думать ? У меня машинка есть в ней неонка и думатель. Неонка светит, а думатель думает.

>Всем любителям крестов срочно компилировать: template<int Depth, int A, typename B> struct K17 { static const int x = K17 <Depth+1, 0, K17<Depth,A,B> >::x + K17 <Depth+1, 1, K17<Depth,A,B> >::x + K17 <Depth+1, 2, K17<Depth,A,B> >::x + K17 <Depth+1, 3, K17<Depth,A,B> >:x + K17 <Depth+1, 4, K17<Depth,A,B> >::x; }; template <int A, typename B> struct K17 <16,A,B> { static const int x = 1; }; static const int z = K17 <0,0,int>::x; int main(void) { }

>О результатах компиляции расскажите дня через 2.

Вот и сам пользуешься DSL. Непонятно только, зачем так убого ?

Результаты будут или только говно на вентилятор?

>>Кстати, математически тоже доказано, что в принципе невозможно написать полностью корректный парсер С++.

>Врешь провокатор. Невозможно написать LALR парсер, однако GLR или LL с этой задачей справляются.

Нет, это просто ты ничего не знаешь что универсальной машины Тьюринга решающей проблему СТОП быть не может. По сему математически корректных парсеров темплейтов С++ вообще не может быть. Never ever.

>Нахера мне думать ? У меня машинка есть в ней неонка и думатель. Неонка светит, а думатель думает.

По вам С++ фонатегам это уже давно заметно.

>фонатегам

Хотел написать - "К логопеду, *", но передумал ... Решил спросить, а поконструктивнее сказать нечего ?

Поконструктивнее выше.

>Нет, это просто ты ничего не знаешь что универсальной машины Тьюринга решающей проблему СТОП быть не может. По сему математически корректных парсеров темплейтов С++ вообще не может быть. Never ever.

Чего-то ты гонишь, СТОП это состояние, а не проблема. Если ты о применимости и не применимости машины Тьюринга определяемого достижением (и не достижением соответственно) состияния СТОП. То проблемой это не является. Давай-ка поконкретнее. И преведи работу с доказательством того, что "в принципе невозможно написать полностью корректный парсер С++"[sic] Меня интересует доказательство для GLR и LL парсеров.

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

template <unsigned int x> int foo() { return foo<x+1>(); }

В тоже время непонятно насколько корректно это "независание" :) И вообще нах такая корректность нужна ?

т.е. фактически это уже не парсер, а полноценный фронтенд :)

>т.е. фактически это уже не парсер, а полноценный фронтенд :) хм, ум ... нипонял ... какой фронт-энд, кому энд и нафига ? И причем здесь парсер ? Шаблоны это гетерогенный немодульный DSEL (Domain specific embedded language), и они парсятся совершенно прекрасно любым компилятором С++ (за исключением багов, которые есть везде). Причем, что интересно они и исполняются тут-же во время компиляции. Бесконечная рекурсия, не камень преткновения парсера - парсер прекрасно с ней работает, и работает так как и ожидалось - почти бесконечно(до исчерпания ресурсов). Если-бы парсер не умел разобрать подобную конструкцию, то он-бы просто выдал синтаксическую ошибку :)

> м, ум ... нипонял ... какой фронт-энд, кому энд и нафига ?

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

> Бесконечная рекурсия, не камень преткновения парсера - парсер прекрасно с ней работает, и работает так как и ожидалось - почти бесконечно(до исчерпания ресурсов).

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

>Я думаю именно это свойство было упомянуто товарищем выше как "некорректное". Язык устроен так, что можно составить программу, которая подвесит транслятор. Это с точки зрения пользователя не есть гуд.

Что значить "не есть гуд" ? Если быдлокодер, на машине Тьюринга, обрабатывает алфавит, в котором осутствует символ соответствующий состоянию "стоп" и не получает результата за конечное время, то кто в этом виноват: машина Тьюринга или быдлокодер ?

Какой нахрен пользователь ? Ты хотел сказать быдлокодер ?

> кто в этом виноват: машина Тьюринга или быдлокодер ?

Виноваты все. Но помимо этих двух виноват еще и тот, кто в язык встроил эту МТ в виде шаблонов, там где возможно было обойтись и без таких сложностей :)

> Ты хотел сказать быдлокодер ?

Не, ты перепутал. Это ты лишний раз хотел сказать быдлокодер.

>Виноваты все. Но помимо этих двух виноват еще и тот, кто в язык встроил эту МТ в виде шаблонов, там где возможно было обойтись и без таких сложностей :)

Ы ... какой суровый бред, просто обалдеть. Я плакаль. Тьюринг виноват !!!! Мочи Тьюринга !!! Еще один виток тролятины.

По пунктам, без эмоций:

1. По определению виноват тот, кто задачу которая заведомо никогда не закончит своё исполнение, подаёт в обработку. Это все равно, что int main(){ while(1); return 0; } обрабатывать. Эта задача закончится когда нибудь ? нет ? Ну млин тогда и С и Ява и Руби и Питон и вообще любой ЯП по твоему определению виноват. Повторю еще раз - шаблоны это DSL или вернее DSEL и их исполнение происходит на этапе компиляции. Повторяю: ИСПОЛНЕНИЕ !!!!!

2. Приведи способ реализаци С++ DSEL, который по твоему мнению наиболее подходит. И который избавит С++ от тех, кто бесконечные рекурсии для обработки подает :)

> Повторю еще раз - шаблоны это DSL или вернее DSEL и их исполнение происходит на этапе компиляции. Повторяю: ИСПОЛНЕНИЕ !!!!!

:) Я с тобой и не спорю, ты очень умен и говоришь очень правильные и в принципе общеизвестные вещи. Просто из-за этого ИСПОЛНЕНИЯ по ошибке разработчика можно спровоцировать зависание компилятора. Сам дизайн языка допускает такую возможность. Разве это хорошо ? Транслятор того же Си, например, никогда не зависнет если он реализован без ошибок. Просто язык не допускает таких конструкций, интерпретация которых приведен к бесконечной рекурсии/циклу. На мой взгляд с одной стороны это хорошо поскольку снимает с программиста лишний геморой, с другой плохо - поскольку отсутствует тьюринг полное расширение для женериков (кстати, что буква E в DSEL означает ?).

> Приведи способ реализаци С++ DSEL, который по твоему мнению наиболее подходит. И который избавит С++ от тех, кто бесконечные рекурсии для обработки подает :)

Я языки не придумываю, я их использую. Но те, кто использует Си как-то обходятся старым добрым препроцессором. Вроде им даже хватает :)

> Ты на нее сам-то смотрел? Или только сылку видел?

Кое-что посмотрел, хотя не слишком много. Если тебя интересует, есть ли там сглаживание шлифтов, прозрачность и 3Д-десктоп, то разочарую -- нет. Однако речь не об этом, а о том, что 200'000 SLOC на LISP'е -- это в разы больше строк на C++.

> С++ нужно изучать как самостоятельный язык

> забейте на потоки, эта позорно реализованая часть STL либо отомрет в ближайшее 10-20 лет, либо её исправят в конце концов.

Теперь расскажи, откуда в STL появились позорные итераторы, если C++ это самостоятельный язык.

> Теперь расскажи, откуда в STL появились позорные итераторы, если C++ это самостоятельный язык.

а что с ними не так ? итераторы - часть стандартной библиотеки.

> а что с ними не так ?

То, что их нужно 2, при том, что два итератора из функции можно вернуть только в std::pair<>, но при этом ни одна библиотечная функция их в таком виде не принимает и не возвращает.

То, что RandomAccessIterator никакого отношения к итераторам, вообще говоря, не имеет.

Это все следствие того, что интерфейс итераторов невообразимо беден вследствие того, что итератор -- не новая продуманная сущность. Iterator -- это "generalized pointer", оттуда и все проблемы: те же, что у pointer'ов + куча своих, т.е. костыль.

> То, что их нужно 2

Не сочти за наезд, я просто необразован в части STL, а нафига их два ? Один для обхода, а другой для проверки не подошел ли первый к последнему элементу ? Если так, то тут согласен, это действительно неудобно, но неудобство минимально. Лично я даже об этом ни разу не задумывался.

> То, что RandomAccessIterator никакого отношения к итераторам, вообще говоря, не имеет.

Итератор, насколько я понимаю, это абстракция инкапсулирующая в себе логику обхода элементов определенной структуры данных. Разные стратегии обхода - разные итераторы. RandomAccessIterator соотвествует обходу с возможностью доступа к произвольному элементу структуры данных.

> Это все следствие того, что интерфейс итераторов невообразимо беден вследствие того, что итератор -- не новая продуманная сущность. Iterator -- это "generalized pointer", оттуда и все проблемы: те же, что у pointer'ов + куча своих, т.е. костыль.

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

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

Ни в одном нормальном языке, к счастью, итераторов нет. Плюсовые
итераторы — это жалкая попытка изобразить map/foreach на языке,
который изначально на такое не способен.

Схема:

(map (lambda (x) (* x 2)) '(1 2 3))

Питон:

[x * 2 for x in (1, 2, 3)]

Примерный аналог на C++ с итераторами:

vector<int> v;
v.push_back(1);
v.push_back(2);
v.push_back(3);
vector<int> v2;
for (vector<int>::iterator i = v.begin(); i != v.end(); i++) {
    v2.push_back(*i * 2);
}

> Схема:
>
>(map (lambda (x) (* x 2)) '(1 2 3))
>
>Питон:
>
>[x * 2 for x in (1, 2, 3)]

Erlang:
1> [X*2 || X <- [1, 2, 3]].
[2,4,6]
2>

tozhe rulez :)

>Просто из-за этого ИСПОЛНЕНИЯ по ошибке разработчика можно спровоцировать зависание компилятора. Сам дизайн языка допускает такую возможность. Разве это хорошо

Да не зависает транслятор ! Он исполняет программу ! Исполняет грёбаный БЕСКОНЕЧНЫЙ КОД который ему быдлокодер подсунул.

>Транслятор того же Си, например, никогда не зависнет если он реализован без ошибок.

У него нет исполнения времени компиляции.

>Просто язык не допускает таких конструкций, интерпретация которых приведен к бесконечной рекурсии/циклу

С не допускает ??? Как не допускает ? Я же пример привел с бесконечным циклом :) вот пример бесконечной рекурсии: int foo(){ return foo(); } int main(){return foo();}. Свалится по переполнению стэка. Тот пример который анонимуси привел - тоже свалится из за недостачи хипа, только очень не скоро, исполнение времени компиляции не шибко быстрая штука :)

>(кстати, что буква E в DSEL означает ?)

Смотри в постах выше - DSEL - Domain Specific Embedded Language.

>Но те, кто использует Си как-то обходятся старым добрым препроцессором

Блин :) ну что ты сравниваешь :)

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

> Да не зависает транслятор ! Он исполняет программу ! Исполняет грёбаный БЕСКОНЕЧНЫЙ КОД который ему быдлокодер подсунул.

Прости пожалуйста. s/зависает/выполняет бесконечный код/ Т.е. помимо ошибок в рантайме пользователь должен ловить возможно нетривиальные ошибки в компайл-тайме. Лично мне этого не очень улыбается.

> С не допускает ??? Как не допускает ?

Я имел в виду в режиме компиляции :)

> Блин :) ну что ты сравниваешь :)

Тем не менее. Используют же.

> Тут речь о разных весовых категориях. Си++ естественно гораздо более низкоуровневый язык, без нормальной поддержки функций высшего порядка, замыканий и сборки мусора. Но зато куда более производительный при правильном обращении.

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

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=clean&a...

>Прости пожалуйста. s/зависает/выполняет бесконечный код/ Т.е. помимо ошибок в рантайме пользователь должен ловить возможно нетривиальные ошибки в компайл-тайме. Лично мне этого не очень улыбается.

Что значит не тривиальные ? Вполне тривиальные. Если человек сознательно использует DSL или как это сейчас модно называть - метапрограмирование, то он должен понимать, что:

а) его DSL/метакод исполняется в режиме компиляции.

б) бесконечные рекурсии в режиме компиляции, абсолютно так-же глупы как и в режиме исполнения.

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

Если эти вещи использовать, то - да :) И производительность и потребление памяти в общем случае страдают. На графиках вроде видно.

> б) бесконечные рекурсии в режиме компиляции, абсолютно так-же глупы как и в режиме исполнения.

Гы. И тем не менее они случаются.

> а нафига их два ? Один для обхода, а другой для проверки не подошел ли первый к последнему элементу ?

Именно так. Ровно как с указателями в C, по образу и подобию которых они создавались:

for( i=begin; i!=end; ++i ) do_something( *i );

> RandomAccessIterator соотвествует обходу с возможностью доступа к произвольному элементу структуры данных.

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

> Приведи пример plz.

Один конкретный пример впечатления не произведет. Впечатление производится в крупном проекте, где используются кучи _разных_ итераторов и при том, что все они, вроде бы "generalized pointers", везде делаются предположения об особенностях конкретных итераторов -- одни не RandomAccess, другие становятся невалидны при вставке/удалении элемента из контейнера, третьи только Forward, четвертые -- не пойми какие const или не const (как у map). В общем, выясняется, что единой концепции iterator нет, но их куча и написать, например, обобщенный sort практически нереально (попробуй отсортировать std::sort'ом std::list).

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

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

> Если эти вещи использовать, то - да :)

Ну про GC ещё можно поспорить, а остальное, при статической типизации — каким образом? Вздор говорите.

По графикам там вообще ничего не видно, по-моему, кроме того, что оба языка предоставляют достаточно возможностей для низкоуровневой оптимизации. Ни ФВП, ни плюсовые классы, ни STL в этих замерах почти не используются. Благо задачи достаточно простые и известные, чтобы можно было их решить хоть на ассемблере голыми руками. А разница в полтора раза на синтетических тестах — это не разница вообще.

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

Да понижает. Я-бы с удовольствием на код посмотрел который для теста использовали. Очень классно сравнивать код с отложеной сборкой мусора и с реал-тайм выделением/удалением памяти. Зато когда сборка мусора начнется все остальное просто притухнет. Этого обмана в сети как мусора, каждый норовит свой супер тест выложить. И ни кода не выложит который для теста использовался, ни опций компилятора. Тут уже чистый С все обгоняют, все кому не лень. Непонятно только как может програма написаная на С быть быстрее самого С. К тому-же garbage collection это костыль, причем совершенно ненужный. В TR1 стандарт внесли smart pointers, которые до этого существовали вне стандарта. У меня в коде уже 5 лет нет ни одной операции delete. И ликов памяти нет, и сборка мусора ненужна.

По поводу iterators и for_each смотри сюда: #include <algorithm>. А твой дичайший код, есть явное незнание STL.

> Ну про GC ещё можно поспорить,

Че тут спорить и так понятно, что GC это основной тормоз и потребитель памяти в любом высокоуровневом языке.

> а остальное, при статической типизации — каким образом? Вздор говорите.

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

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

На все это уходят вычислительные ресурсы

> А разница в полтора раза на синтетических тестах — это не разница вообще.

Что-то мне подсказывает, что разница на реальных проектах будет куда больше чем в полтора раза :)

> В TR1 стандарт внесли smart pointers, которые до этого существовали вне стандарта.

Допустим, есть набор объектов, выделяемых на куче, которые рассматриваются как узлы произвольного направленного графа. Ребра графа образуются при помощи указателей на соседние узлы, которые держат сами узлы.

Что произойдет в этом случае со smart pointer'ами? Правильно, cyclic references -> memory leak. То, что у вас этого не возникало, говорит об одном из двух: либо отсутствовали достаточно сложные задачи, либо человек делал работу машины по разруливанию управления памятью.

> Один конкретный пример впечатления не произведет...

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

> ни разу такой мешанины из итераторов не видел.

Что. неужели не видел проектов, в которых одновременно используются std::vector, std::list и std::map?