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

AVK>Сравнивать надо компиляторы одинаковых языков.

Одинаковых — это как ? Turbo Pascal и Object Pascal — это одинаковые ? Второй сложнее, да, но не в десять раз. А уж совсем одинаковые — где же взять язык, который за 20 лет совсем не менялся ?

PD>>+1 насчет рефакторинга. Интеллисенс там есть, хоть и не такой.

AVK>Вот именно что тоже убогий.

Ну это кому как. Мне достаточно. А еще есть Visual Assist.


PD>>Ну слава богу, хоть ТурбоПаскаль однопроходной. А VC++ — сколько проходов все же ?

AVK>Не интересовался.

Два.

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

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

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

AVK>Потому что С++ существенно более старый язык.

О да. Вот с этим соглашусь.

А что касается C#, то вряд ли он многопроходной. Слишком уж он быстро компилирует, быстрее, чем С++. Ну да, в нем нет оптимизации, так и для С++/Debug ее тоже нет.


PD>>то да, предописание необходимо

AVK>Вот именно. А в Java и C# такой необходимости нет, там forward declaration отсутствует как класс.



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

В том же С вполне можно было бы допустить

struct A {
struct B* ptr;
};

struct B {...};

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

PD>>Но из этого, в общем, мало что следует.

AVK>Из этого следует то, что язык специально заточен под минимальное количество проходов. А минимальное количество проходов нужно как раз чтобы компилятору хватало малого объема памяти.

Так, хоть с тем, что в С++ проходов мало, ты наконец согласился. Прогресс.

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

PD>>Ты хоть представление имеешь о том, как компиляция в С/C++ идет ?

AVK>Павел, если есть желание заняться пенисометрией, то не советую. У меня все равно длиннее. Ты не у меня пробелы в знаниях ищи,

Глупо. Если ты заявил, что для компиляции в С++ нужна какая-то DLL, то не удивляйся, когда получаешь такие разъяснения. Не хочешь их получать — не делай такие заявления, а сначала разберись.

>а подумай, как это связано с лимитом потребления памяти.

Что связано ? DLL ? Никак не связано — я тебе уже объяснил, что она там не используется никак.

P.S. DLL- вообще-то элемент ОС Windows. И к языку С++ отношения не имеют.

PD>>Думаю, это просто означает, что не очень хорошо продуман функционал.

AVK>Нет, это означает что программа не качественна и не полностью удовлетворяет требованиям.

Именно так.

PD>> Потому что невозможно его использовать целиком одновременно.

AVK>Возможно.

Именно так.

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

PD>>Да, знаю.

AVK>Ну так вот в основном эти пакеты память и жрут.

Так вот и надо выяснить, нужны ли они все одновременно.

P.S. Будет время — посмотрю студию с помощью VMMAP и напишу.

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

ВВ>>А для того, что "скомпилировать программу с одной только dll" проблем тоже как-то не видно, достаточно, чтобы для этой DLL импорт-директивы были прописаны именно в том виде, в котором их понимает конкретный компилятор.
PD>Маленькое уточнение. Для VC++ — не импорт-директивы, а библиотека импорта, отдельный файл. Обычно прилагается к DLL, но при необходимости может быть сгенерирован по DLL
PD>http://forum.shelek.ru/index.php/topic,3621.0.html

Если ты про def-файл, то если маразм мне не изменяет, он используется для декорирования имен и можно в принципе без него. Хотя бы через extern C. В любом случае, это нюансы.
"Скомпилировать программу с DLL" можно без проблем. Другой вопрос, что конкретно для С++ это малоприменимо. Ну так для него и под дотнетом это применимо мало.

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

ВВ>Если ты про def-файл, то если маразм мне не изменяет, он используется для декорирования имен и можно в принципе без него.

Я имею в виду, что если есть только DLL без исходников, то можно восстановить .lib.

>Хотя бы через extern C.

Просто extern C не поможет — будет unresolved external.

>В любом случае, это нюансы.

Конечно.

ВВ>"Скомпилировать программу с DLL" можно без проблем.

Поясни.

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

>>Хотя бы через extern C.
PD>Просто extern C не поможет — будет unresolved external.

Ну __declspec dllimport еще добавь . Раз уж мы о нюансах говорим, то def-то как раз не для того, чтобы указать, что импортируется, а чтобы у импортируемых функций красивые имена были.

ВВ>>"Скомпилировать программу с DLL" можно без проблем.
PD>Поясни.

Вообще Андрей-то рекламирует модный ныне компонентно-ориентированный, так сказать, подход, когда все библиотеки для того же шарпа распространяются в виде DLL. Причем по принципу compile once run "everywhere". Статическая линковка и "файлы в специальном формате" отсутствуют как класс.

Все, что я хотел сказать — подобный подход возможен и для нейтив кода, без проблем. Точно так же как и для 100% managed кода, написанного на C++\CLI с ключиком /pure возможна статическая линковка, а в некоторых случаях и необходима, если ты, скажем, хочешь написать шаблонную библиотеку.

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

AVK>>Зато они работают быстрее и качественнее.
PD>Насчет качественее — не спорю. Насчет быстрее... Давай сравним. ТурбоПаскаль 1.0 на Ямахе с тактовой частотой 2 МГц и памятью в 64К компилировал программу в 1000 строк несколько секунд. Сколько времени надо, чтобы откомпилировать программу размером в 1 млн строк на процессоре в 2 Ггц ? Очевидно, тоже несколько секунд. Давай сюда этот компилятор!

А ничего, что компиляторы поумнее стали? Много дополнительной работы делают. Вон тот же компилятор C# вывод типов делает.

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

Да и зачем нам турбопаскель на Ямахе-то? Давай с VC сравним Это к вопросу о "количестве проходов".

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

PD>А что касается C#, то вряд ли он многопроходной. Слишком уж он быстро компилирует, быстрее, чем С++. Ну да, в нем нет оптимизации, так и для С++/Debug ее тоже нет.

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

И оптимизацию, какую-никакую, но компилятор Шарпа все же делает. Достаточно сравнить IL в релизе и дебаге.

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

PD>Одинаковых — это как ?

А вот так. Если хочешь сравнивать, нужно брать одинаковый язык.

PD> Turbo Pascal и Object Pascal — это одинаковые ?

Если речь о современном Object Pascal, то нет.

PD> Второй сложнее, да, но не в десять раз.

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

PD> А уж совсем одинаковые — где же взять язык, который за 20 лет совсем не менялся ?

С++

PD>А что касается C#, то вряд ли он многопроходной.

Т.е. Липперт врет? Или ты его не читал?

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

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

PD>Так, хоть с тем, что в С++ проходов мало, ты наконец согласился.

А я никогда этого и не отрицал.

PD>Могу лишь повториться — двух проходов хватит всегда. Малый объем памяти тут ни при чем, так как проход — это просмотр исходного текста.

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

PD>Глупо.

Именно

PD> Если ты заявил, что для компиляции в С++ нужна какая-то DLL

Я этого не заявлял.

AVK>>Ну так вот в основном эти пакеты память и жрут.

PD>Так вот и надо выяснить, нужны ли они все одновременно.

Нужны.

PD>P.S. Будет время — посмотрю студию с помощью VMMAP и напишу.

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

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

А я нигде не писал, что он для нейтив кода невозможен. Я писал, что он невозможен конкретно для современных компиляторов С++.

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

F>> Очевидно, что тот компилятор с памятью в 64К может и не скомпилировать 1 млн. строк вообще хотя бы ввиду отсутствия этой самой памяти.
PD>Я не про память , а про время писал. Ускорили процессор в 1000 раз — давайте в 1000 раз большую скорость.
1) Тактовая частота процессора — лишь один из показателей, который влияет на производительность системы в целом. А кол-во памяти ты упорно указываешь.
2) Давай вернём уровень оптимизаций на 20 лет назад — будет быстрее компилировать.

F>> Да и с оптимизациями в ТурбоПаскале 1.0 было совсем туго.
PD>И в C# не лучше. Оптимизирует потом JIT
То, пусть немногое, что он может — он оптимизирует, безусловно что-то перекладывая и на плечи JIT.

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

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

>>>Хотя бы через extern C.
PD>>Просто extern C не поможет — будет unresolved external.

ВВ>Ну __declspec dllimport еще добавь . Раз уж мы о нюансах говорим, то def-то как раз не для того, чтобы указать, что импортируется, а чтобы у импортируемых функций красивые имена были.

Да не поможет же. Хоть extern, хоть __declspec dllimport . Нужна еще .lib — библиотека импорта. Откуда линкеру эту функцию брать-то ? А вот если ее нет, то можно из DLL слепить, через def-файлы.

ВВ>>>"Скомпилировать программу с DLL" можно без проблем.
PD>>Поясни.

ВВ>Вообще Андрей-то рекламирует модный ныне компонентно-ориентированный, так сказать, подход, когда все библиотеки для того же шарпа распространяются в виде DLL. Причем по принципу compile once run "everywhere". Статическая линковка и "файлы в специальном формате" отсутствуют как класс.

А С++ тут при чем ?

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

Нет. Для native кода из DLL еще можно вытянут библиотеку импорта. Хедеры не вытянешь, разве что займешься undecorate, но это не всегда возможно.

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

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

Это-то и непонятно. Почему невозможен-то? Dynamic DLL везде поддерживается.

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

ВВ>А ничего, что компиляторы поумнее стали? Много дополнительной работы делают.

Компиляторы дополнительной работы не делают. Они компилируют из исходного текста в объектный (или IL). Плюс оптимизируют, иногда.

А вот IDE стали умнее намного, да. Плюс отладчики и т.д.

>Вон тот же компилятор C# вывод типов делает.

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

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

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

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

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

ВВ>Да и зачем нам турбопаскель на Ямахе-то? Давай с VC сравним Это к вопросу о "количестве проходов".

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

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


ВВ>И оптимизацию, какую-никакую, но компилятор Шарпа все же делает. Достаточно сравнить IL в релизе и дебаге.

Может, что-то и делает, но меня тут 100 раз убеждали, что делает все же JIT

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


PD>> А уж совсем одинаковые — где же взять язык, который за 20 лет совсем не менялся ?

AVK>С++


Компиляторы C++ даже 10 летней давности сильно примитивнее современных. А уж 20 лет назад
это был совсем другой язык.

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

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

Боже мой, а кто же это делает? Неужели IDE?
И очень интересно, каким образом это может не иметь отношения к компиляции.

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

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

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

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

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

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

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

ВВ>>И оптимизацию, какую-никакую, но компилятор Шарпа все же делает. Достаточно сравнить IL в релизе и дебаге.
PD>Может, что-то и делает, но меня тут 100 раз убеждали, что делает все же JIT

Вот если тебе действительно интересно — кто мешает взять и проверить?
Оптимизацию делает и компилятор Шарпа (при компиляции в промежуточный байт-код) *и* Джит. Некоторые вещи, как например инлайнинг, делает только Джит.

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

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

PD>>> А уж совсем одинаковые — где же взять язык, который за 20 лет совсем не менялся ?
AVK>>С++
FR>Компиляторы C++ даже 10 летней давности сильно примитивнее современных. А уж 20 лет назад
FR>это был совсем другой язык.

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

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

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

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

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

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

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

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

    void bar()
    {
    }
};

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

AVK>>Потому что С++ существенно более старый язык.

PD>О да. Вот с этим соглашусь.

PD>А что касается C#, то вряд ли он многопроходной. Слишком уж он быстро компилирует, быстрее, чем С++. Ну да, в нем нет оптимизации, так и для С++/Debug ее тоже нет.

Да, наверно, один из авторов компилятора C#, наглым образом, наврал про то, как работает этот компилятор.

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

AVK>А вот так. Если хочешь сравнивать, нужно брать одинаковый язык.

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

PD>> Второй сложнее, да, но не в десять раз.

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

Да мне дела нет, вызывает или нет. Вот тебе пример неизменившегося языка (сам просил), вот тебе и результаты. Моя экспертная оценка тут вообще ни при чем.

PD>> А уж совсем одинаковые — где же взять язык, который за 20 лет совсем не менялся ?

AVK>С++

С++ менялся, и сейчас меняется. Вот С — не менялся.


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

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

Да ну ?

struct A {
struct B* ptr;
};
struct B { int i;};

Нет forward declarations ? Нет.

Проходим по тексту. Заносим все имена в контейнер. Обнаружив неописанное имя (B) делаем пометку, что неописано.
Проходим второй раз. Разрешает все неописанные имена по контейнеру.

Вот и все.

PD>>Так, хоть с тем, что в С++ проходов мало, ты наконец согласился.

AVK>А я никогда этого и не отрицал.

Слава богу

PD>>Могу лишь повториться — двух проходов хватит всегда. Малый объем памяти тут ни при чем, так как проход — это просмотр исходного текста.

AVK>Если весь код программы в памяти — количество проходов на производительность сильно не влияет. Если же памяти мало, то держать все исходники или полное AST в памяти не получится, значит надо общаться с диском. И вот тут то проходы и становятся очень дорогими.

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

Кстати, то, что ты называешь памятью — это либо ОП, либо своп. Тот же диск, вообще говоря. А резидентную память только в ядре дают, а 3 кольцу — через AWE разве, ну там еще и VirtualLock, но это не пройдет — надо включать привилегию Lock Pages, а ее не включают для компиляции.


PD>> Если ты заявил, что для компиляции в С++ нужна какая-то DLL

AVK>Я этого не заявлял.

А это что ?

AVK>Т.е. компилятору С достаточно одной только dll, чтобы скомпилировать программу с ее использованием?

http://rsdn.ru/forum/philosophy/3753722.1.aspx

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

С или С++ — никакой разницы в этом плане нет.

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

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

F> 1) Тактовая частота процессора — лишь один из показателей, который влияет на производительность системы в целом.

Да. Еще и кэш памяти, еще и скорость винта и т.д. И все это возросло на порядки (а кэш — в бесконечность раз, ибо его не было)


>А кол-во памяти ты упорно указываешь.

Зря указал.

F> 2) Давай вернём уровень оптимизаций на 20 лет назад — будет быстрее компилировать.

А в Debug ? Нет там оптимизации — запрещена опциями.