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

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

ВВ>>>Вон тот же компилятор C# вывод типов делает.
PD>>Вообще-то это делает не компилятор ИМХО. Если это в него и включено, то к собственно компиляции отношения не имеет.

ВВ>Боже мой, а кто же это делает? Неужели IDE?

Откуда мне знать ? Спроси Андрея. Я лишь одно говорю — к собственно компиляции это отношения не имеет.

ВВ>И очень интересно, каким образом это может не иметь отношения к компиляции.

ВВ>>>Потом тот же C# на самом деле очень быстро компилирует.
PD>>Потому что не оптимизирует. С++ тоже быстро в Debug компилирует, а в Release — не очень. Оптимизация.

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

C# быстрее.

ВВ>Как будто блин речь о том, что в режиме full как-то там optimization, когда компиляция сначала вообще идет в промежуточный формат, VC тормозит, а все остальное время летает.

Не летает, увы.

PD>>Про 2х-герцовую машину не скажу, но на домашнем C2D 3Ггц практически все что есть — собирается действительно за несколько секунд.
PD>>А Андрей утверждает, что он многопроходной

ВВ>Это утверждает не Андрей, а Эрик Липперт
ВВ>И да, действительно многопроходной. Ну значит, видимо, не в проходах проблема.

Или в определении того, что такое проход

ВВ>>>Да и зачем нам турбопаскель на Ямахе-то? Давай с VC сравним Это к вопросу о "количестве проходов".
PD>>Что с VC сравним и зачем ? Все, что я хотел сказать своим сравнением с TP — это то, что тактовая увеличилась в 1000 раз, память — в десятки тысяч, а вот скорость не то, чтобы очень.

ВВ>А сложность языков во сколько раз увеличилась?

Языка С — в 1.0000 раз. А компилятор C VC по сравнению с ТурбоС 199? года быстрее в 1000 раз не стал.

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

C>Здравствуйте, Pavel Dvorkin, Вы писали:

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

PD>>>>>>Откуда такая информация ? Ссылку дай, только не по экзотическим языкам.

AVK>>>>>http://blogs.msdn.com/ericlippert/archive/2010/02/04/how-many-passes.aspx

PD>>>>Ну что же, если в C# это нужно — на здоровье. В С++ — нет.

C>

C>class Foo
C>{
C>public:
C>    void foo()
C>    {
C>        bar();
C>    }

C>    void bar()
C>    {
C>    }
C>};
C>

C>Вопрос на засыпку, как однопроходный компилятор должен компилировать метод Foo::foo? Ну и про 2-х фазный поиск имён, опять же, не забываем. Так, что количество проходов необходимых для компиляции обоих языков одинаковое.

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

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

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

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

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

ВВ>Одно дело язык, другое дело — компилятор. Хотя речь-то на самом деле о компиляторах, а не о языках.

Так язык реально тоже изменился, никто ни писал и не мог писать 10 лет назад так как сейчас, компиляторы просто
не поддерживали стандарт в должной мере, попробуй последний boost например скомпилировать на старье.

ВВ>У С, кстати, как я понимаю, последний стандарт С99, последняя версия стандарта С++ тоже где-то в этом районе была утверждена. Т.е. ей порядка 10 лет где-то (+/-).

У C++ — 98 плюс косметические улучшения в 2003.
Но проблема в том что более — менее нормально стандарт начал поддерживаться как раз наверно с 2003 — 2004 года, плюс тогда же появился и начал массово использоваться современный стиль программирования.

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

Pzz>"Сложение" массивов требует аллокации памяти и копирования. И та и другая операции при большом объеме достаточно дорогие. "Сложение" списков требует лишь перенастройки пары указателей.

Ну вот, хоть кто-то напомнил о чем топик

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

PD>>>>>>>Откуда такая информация ? Ссылку дай, только не по экзотическим языкам.

AVK>>>>>>http://blogs.msdn.com/ericlippert/archive/2010/02/04/how-many-passes.aspx

PD>>>>>Ну что же, если в C# это нужно — на здоровье. В С++ — нет.

PD>Почитай внимательно мои постинги, я же ясно говорю, что компилятор должен быть двухпроходным для решения этих проблем. Но для их решения больше 2 проходов не требуется.

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

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

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

В теории — да. А на практике ведь нужно как-то бороться с циклическими зависимостями?

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

Pzz>>"Сложение" массивов требует аллокации памяти и копирования. И та и другая операции при большом объеме достаточно дорогие. "Сложение" списков требует лишь перенастройки пары указателей.

ВВ>В теории — да. А на практике ведь нужно как-то бороться с циклическими зависимостями?

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

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

PD>Ну и пожалуйста. Берем C из VC и C из ТурбоС 198x года. Тактовая IBM PC XT 4.77 MHz, а сейчас в 800 раз больше (это даже не учитывая многоядерности, кэша процессора и т.д.) Язык практически без изменений. Винчестер намного быстрее. А скорость в 1000 раз отнюдь не возросла.

Цифры в студию. На слово я тебе не верю.

AVK>>Без forward declaration — нельзя.

PD>Да ну ?

Возвращаемся к старому вопросу — всегда ли в С++ можно обойтись без forward declaration?

PD>Открой для себя memory-mapped файлы. Они и память, они и диск. И ненужные страницы в ОП отсутствуют, а понадобятся — подкаччиваются.

При чем тут я? Я тебе объясняю, зачем в свое время боролись за количество проходов.

AVK>>Я этого не заявлял.
PD>А это что ?
AVK>>Т.е. компилятору С достаточно одной только dll, чтобы скомпилировать программу с ее использованием?
PD>http://rsdn.ru/forum/philosophy/3753722.1.aspx

Автор: AndrewVK
Дата: 29.03.10

Знаки препинания видишь? Это был вопрос.

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

ВВ>>Потом тот же C# на самом деле очень быстро компилирует.

PD>Потому что не оптимизирует. С++ тоже быстро в Debug компилирует, а в Release — не очень. Оптимизация.

PD>Про 2х-герцовую машину не скажу, но на домашнем C2D 3Ггц практически все что есть — собирается действительно за несколько секунд.

PD>А Андрей утверждает, что он многопроходной

Это не я утверждаю, это Липперт утверждает. Прочти наконец статью, ссылку на которую ты сам просил.

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

PD>Откуда мне знать ? Спроси Андрея. Я лишь одно говорю — к собственно компиляции это отношения не имеет.

Давай начнем сначала. Что такое, по твоему, вывод типов?

ВВ>>И да, действительно многопроходной. Ну значит, видимо, не в проходах проблема.

PD>Или в определении того, что такое проход

А что, у тебя есть какое то непонимание того, что такое проход?
http://en.wikipedia.org/wiki/Multi-pass_compiler

A multi-pass compiler is a type of compiler that processes the source code or abstract syntax tree of a program several times. This is in contrast to a one-pass compiler, which traverses the program only once. Each pass takes the result of the previous pass as the input, and creates an intermediate output. In this way, the (intermediate) code is improved pass by pass, until the final pass emits the final code.

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

ВВ>Это-то и непонятно. Почему невозможен-то?

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

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

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

Т.е. вся проблема в том, что в случае .NET Assembly манифест встроен в эту самую assembly, а тут он предоставляется отдельно?
Как-то я тут не вижу кардинальной разницы.

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

PD>Потому что не оптимизирует. С++ тоже быстро в Debug компилирует, а в Release — не очень. Оптимизация.

PD>Про 2х-герцовую машину не скажу, но на домашнем C2D 3Ггц практически все что есть — собирается действительно за несколько секунд.

Наверняка мелочевка. Один рабочий проект у меня собирается где то почти за час на 2гц.

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

PD>>Потому что не оптимизирует. С++ тоже быстро в Debug компилирует, а в Release — не очень. Оптимизация.
PD>>Про 2х-герцовую машину не скажу, но на домашнем C2D 3Ггц практически все что есть — собирается действительно за несколько секунд.
I>Наверняка мелочевка. Один рабочий проект у меня собирается где то почти за час на 2гц.

Самый большой домашний проект — 3 тыс. файлов где-то, собирается за несколько секунд. У вас видимо (если речь действительно про шарп) во время сборки происходит много чего еще помимо собственно компиляции.

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

ВВ>Т.е. вся проблема в том, что в случае .NET Assembly манифест встроен в эту самую assembly, а тут он предоставляется отдельно?

Проблемы никакой нет.

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

ВВ>>Боже мой, а кто же это делает? Неужели IDE?
PD>Откуда мне знать ? Спроси Андрея. Я лишь одно говорю — к собственно компиляции это отношения не имеет.
ВВ>>И очень интересно, каким образом это может не иметь отношения к компиляции.
PD>Откуда мне знать ? Спроси Андрея. Я лишь одно говорю — к собственно компиляции это отношения не имеет.

У меня есть серьезное подозрение, что ты не до конца понимаешь, о чем речь. Погугли на type inference.

ВВ>>Это утверждает не Андрей, а Эрик Липперт
ВВ>>И да, действительно многопроходной. Ну значит, видимо, не в проходах проблема.
PD>Или в определении того, что такое проход

Дай свое определение, вот и посмотрим об одном мы говорим или о разном.

ВВ>>А сложность языков во сколько раз увеличилась?
PD>Языка С — в 1.0000 раз. А компилятор C VC по сравнению с ТурбоС 199? года быстрее в 1000 раз не стал.

ОК, "сложность языков" некорректная формулировка. Переформулируем.
А сложность компиляторов во сколько раз увеличилась?

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

PD>>>Потому что не оптимизирует. С++ тоже быстро в Debug компилирует, а в Release — не очень. Оптимизация.
PD>>>Про 2х-герцовую машину не скажу, но на домашнем C2D 3Ггц практически все что есть — собирается действительно за несколько секунд.
I>>Наверняка мелочевка. Один рабочий проект у меня собирается где то почти за час на 2гц.

ВВ>Самый большой домашний проект — 3 тыс. файлов где-то, собирается за несколько секунд. У вас видимо (если речь действительно про шарп) во время сборки происходит много чего еще помимо собственно компиляции.

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

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

I>Так речь про С++ или где ? Не пойму, как можно быстро компилить проект с шаблонами.

Смотри D, там шаблоны еще наваристей чем в C++ а компилируется на порядок шустрее.

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

F>> 1) Тактовая частота процессора — лишь один из показателей, который влияет на производительность системы в целом.
PD>Да. Еще и кэш памяти, еще и скорость винта и т.д. И все это возросло на порядки (а кэш — в бесконечность раз, ибо его не было)
Именно. Но ты при этом считаешь, что мы должны получить 1000x, тогда как в таких задачах на верхнюю планку будет влиять скорость доступа к памяти, а она у нас пока всё ещё значительно ниже. Кеш безусловно помогает, но чем больше размер исходных файлов -> размер внутренних структур -> тем мы больше будем иметь промахов.

F>> 2) Давай вернём уровень оптимизаций на 20 лет назад — будет быстрее компилировать.
PD>А в Debug ? Нет там оптимизации — запрещена опциями.
Опции дело такое — constant folding, например, афаик — совсем не отключается.
Диагностика ошибок всё таки стала лучше (применительно к C++), а значит и анализа — больше.
TP/Delphi и прочие — и сейчас быстро компилируются, что в релизе, что в дебаге. На мелких проектах я лично успеваю у коллег только моргнуть. TP5.5 вот ощутимее дольше компилировал, по сравнению с 1.0 — но откомпиленные им программы просто летали, опять же по сравнению с 1.0...
C/C++ — никогда быстро не компилировался и врядли будет, пока есть километры хидеров.
Собственно о чем спорим?