Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>Хотя... ИМХО 500 М достаточно, чтобы разместить все плагины на свете. LVV>А помнишь, 512 К — это было СТОЛЬКО памяти!!! Весь институт одновременно сидел...
Помню. И компилятор Паскаль ДВК-2 И ТурбоПаскаль Ямахи в 64 Кб тоже помню. Компилировал, как ни странно.
AVK>>>Это тебе так только кажется за незнанием предмета. PD>>Возможно. И все же — что там занимает 1.5 Г АП ? LVV>1.5 Гига — это БЕСКОНЕЧНО МНОГО...
Это мы понимаем. Это им не понять.
LVV>Скорее всего это произойдет после повсеместного перехода ОС на x64.
Что-то это добро побеждает, побеждает и никак победить не может (C) Айболит-66
Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>>Это тебе так только кажется за незнанием предмета.
PD>Возможно. И все же — что там занимает 1.5 Г АП ?
Много чего. Например кеш пропарсенных исходников всего солюшена. Или целое море dll'ек. Ну и, конечно, WPF. 1.5Гб, кстати, это после того как они долго чистили на предмет занимаемого спейса. Без чистки 2010 студия без всяких расширений дохла по исчерпанию АП.
PD>Я 2010 не ставил, но как-нибудь посмотрю АП в 2008.
В 2008 ситуация немного полегче. Если решарпер не ставить, то АП хватает. А в 2010 они сами же на свои грабли наступили без всякого решарпера.
AVK>>Нет, и не собираются.
PD>Жаль.
Не то слово. Вот уж кому 64 бита нужно, так это студии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Много чего. Например кеш пропарсенных исходников всего солюшена.
Вообще-то ИМХО размер пропарсенных исходников не должен быть намного больше размера самих исходников. Скорее наоборот — хранить имена полей и переменных в N экземплярах там не надо, а они много (в %) места занимают. Аргумент здесь простой — умели же компилировать на машинах с памятью 64 К программы с намного большим размером исходников.
>Или целое море dll'ек.
Это да. Но их просто надо бы уложить компактно. Не думаю, что их объем так уж велик сам по себе.
>Ну и, конечно, WPF. 1.5Гб, кстати, это после того как они долго чистили на предмет занимаемого спейса. Без чистки 2010 студия без всяких расширений дохла по исчерпанию АП.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вообще-то ИМХО размер пропарсенных исходников не должен быть намного больше размера самих исходников.
Во-первых нет, как минимум связи между нодами в AST в виде указателей отожрут вполне сравнимо с исходым текстом. Во-вторых несколько сотен мег исходников вполне реальая ситуация. В-третьих, помимо пропарсенных исходников нужны еще и индексы, которые тоже немало занимают.
PD> Скорее наоборот — хранить имена полей и переменных в N экземплярах там не надо
Для IDE — надо, иначе ни рефакторинга, ни интеллисенса.
PD>Аргумент здесь простой — умели же компилировать на машинах с памятью 64 К программы с намного большим размером исходников.
То что умели компилировать на машинах с 64К, приходилось сильно урезать. Те же хидеры в C как раз из-за этого пришлось делать.
>>Или целое море dll'ек.
PD>Это да. Но их просто надо бы уложить компактно.
Опять же, ты плохо разбираешься в предмете. Студия это не монолитный код, а сравнительно компактный shell с целой кучей плагинов, разрабатываемых независимыми командами. И все это приправлено нехилым грузом совместимости и стабов для перехода между неуправляемым кодом и .NET.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Вообще-то ИМХО размер пропарсенных исходников не должен быть намного больше размера самих исходников.
AVK>Во-первых нет, как минимум связи между нодами в AST в виде указателей отожрут вполне сравнимо с исходым текстом.
Не думаю. Ноды — они, конечно, ноды и связи — они тоже, но вот под все вхождения имени переменной надо (strlen+1) ее + N*4 байта, не более. А ИМХО эти имена процентов 30-40 как минимум исходного текста занимают. Да и методы те же можно покомпактнее хранить, чем в виде исходного текста.
>Во-вторых несколько сотен мег исходников вполне реальая ситуация.
Реальная, да, но все же не типичная.
PD>> Скорее наоборот — хранить имена полей и переменных в N экземплярах там не надо
AVK>Для IDE — надо, иначе ни рефакторинга, ни интеллисенса.
Почему это ? Кто мешает восстановить текст по внутренней компактной структуре, изоморфной тексту ? В нем же избыточности до черта!
PD>>Аргумент здесь простой — умели же компилировать на машинах с памятью 64 К программы с намного большим размером исходников.
AVK>То что умели компилировать на машинах с 64К, приходилось сильно урезать. Те же хидеры в C как раз из-за этого пришлось делать.
Хедеры тут вообще ни при чем. Они просто, чтобы не писать то, что я писать не обязан. Не буду же я все прототипы из stdio.h сам писать! Кстати, и хедеров, строго говоря, нет. Есть #include, а уж что именно там — можно .h с только декларациями, а можно и .c с дефинициями. Это просто способ организации текста.
>>>Или целое море dll'ек.
PD>>Это да. Но их просто надо бы уложить компактно.
AVK>Опять же, ты плохо разбираешься в предмете. Студия это не монолитный код, а сравнительно компактный shell с целой кучей плагинов, разрабатываемых независимыми командами.
Поверь, я это знаю. Но вот как эти плагины работают — другой вопрос. Загружать их все в ОП совсем не обязательно. Если уж на то пошло, компилятор C++ тоже "плагин", но запускается он как отдельный процесс и АП не ворует у студии.
>И все это приправлено нехилым грузом совместимости и стабов для перехода между неуправляемым кодом и .NET.
За что боролись... .
Одно непонятно — а нас-то (С++) за что на это монстр посадили ? Продолжили бы развивать VS6.0 для C++, ну а вам свою студию совсеми этими прелестями
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не думаю. Ноды — они, конечно, ноды и связи — они тоже, но вот под все вхождения имени переменной надо (strlen+1) ее + N*4 байта, не более. А ИМХО эти имена процентов 30-40 как минимум исходного текста занимают. Да и методы те же можно покомпактнее хранить, чем в виде исходного текста.
Еще раз, ты не в теме. Не все так просто.
PD>Реальная, да, но все же не типичная.
Когда я говорил про то, что Решарперу не хватает АП, речь шла именно про такие проекты.
AVK>>Для IDE — надо, иначе ни рефакторинга, ни интеллисенса.
PD>Почему это ? Кто мешает восстановить текст по внутренней компактной структуре, изоморфной тексту ?
Перформанс.
PD>Хедеры тут вообще ни при чем.
При чем. Без хидеров для ресолва приходится держать в памяти все символьные таблицы.
PD>Поверь, я это знаю. Но вот как эти плагины работают — другой вопрос.
Как бы они не работали — под каждый надо выделять АП для имаджа и рабочих структур.
PD> Загружать их все в ОП совсем не обязательно.
Не обязательно. Но отталкиваться надо от ситуации, когда они все загружены.
PD> Если уж на то пошло, компилятор C++ тоже "плагин", но запускается он как отдельный процесс и АП не ворует у студии.
Когда я писал про плагины, речь шла не о компиляторе, а о том что в студии называется package
PD>Одно непонятно — а нас-то (С++) за что на это монстр посадили ?
Разрабатывать несколько сред дорого и плохо с точки зрения маркетинга.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
PD>>Не думаю. Ноды — они, конечно, ноды и связи — они тоже, но вот под все вхождения имени переменной надо (strlen+1) ее + N*4 байта, не более. А ИМХО эти имена процентов 30-40 как минимум исходного текста занимают. Да и методы те же можно покомпактнее хранить, чем в виде исходного текста.
AVK>Еще раз, ты не в теме. Не все так просто.
Я не в теме, да, и не все так просто, но ведь 20-30 лет назад было не проще, а таки было. А зная, как сейчас умеют транжирить ресурсы, я имею основание предположить, что то, что тебе кажется нормальным, в действительности могло занимать раз так в 5-10 меньше места. Просто потому, что прецедент-то был.
AVK>Когда я говорил про то, что Решарперу не хватает АП, речь шла именно про такие проекты.
Я полагал, мы давно уже не про Решарпер говорим, а обсуждаем, кто и зачем 1.5 Г АП скушал. Про DLL и т.д.
PD>>Почему это ? Кто мешает восстановить текст по внутренней компактной структуре, изоморфной тексту ?
AVK>Перформанс.
Ох, что-то плохо верю. При хорошей внутренней структуре данных обратная генерация исходного текста будет происходить очень быстро. Да и так — все равно хранят они в этом кеше что-то во внутреннем формате, не сами же исходники. И решарпер — он что, исходники парсит заново ? Нет, наверное.
Кстати, если уж на то пошло — рефлектор же умеет восстановить код по IL. И довольно шустро. PD>>Хедеры тут вообще ни при чем.
AVK>При чем. Без хидеров для ресолва приходится держать в памяти все символьные таблицы.
И что ? Этим символов в проекте тысячи, десятки тысяч, ну пусть сотня. Ты попробуй напиши со всей своей командой программу, в которой 100000 имен, а потом поговорим . И библиотеки тут ничего не изменят — там тоже не миллионы имен. Весь нелюбимый тобой Win API — несколько тысяч.
PD>>Поверь, я это знаю. Но вот как эти плагины работают — другой вопрос.
AVK>Как бы они не работали — под каждый надо выделять АП для имаджа и рабочих структур.
AVK>Не обязательно. Но отталкиваться надо от ситуации, когда они все загружены.
Вообще-то отталкиваться нужно от ситуации, когда загружено то, что надо. Вот тебе классический пример. Я с аськой начинал работать, когда на машине было не то 8, не то 16 Мб. Ну и она там сколько-то занимала, и , в общем, не мешала. Сейчас она сама в 16 не уверен, что уложится. А 99% ее использования как тогда было, так и сейчас (строку набрать да отослать, ответ посмотреть). Ну и сидели бы все оставшиеся фичи себе на диски и ждали, когда их в АП призовут. А по минованию надобности выгонят. Нечего им там сидеть.
PD>> Если уж на то пошло, компилятор C++ тоже "плагин", но запускается он как отдельный процесс и АП не ворует у студии.
AVK>Когда я писал про плагины, речь шла не о компиляторе, а о том что в студии называется package
Тут я действительно не очень в курсе. Про package знаю гл. образом то, что они иногда ругаются, что у них что-то не так, но после этого студия все же работает, по крайней мере в части С++.
PD>>Одно непонятно — а нас-то (С++) за что на это монстр посадили ?
AVK>Разрабатывать несколько сред дорого и плохо с точки зрения маркетинга.
Ну вообще-то до поры до времени VB был вполне отдельным от студии продуктом. И FoxPro тоже, да и остается , если его не похоронили (что-то о нем почти и не слыхать). А вот Compaq Fortran вполне неплохо в эту студию встраивался, да и Intel C++, Intel Fortran...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я не в теме, да, и не все так просто, но ведь 20-30 лет назад было не проще
Было. 20 лет назад просто не было аналогичных по функционалу IDE.
PD>Я полагал, мы давно уже не про Решарпер говорим, а обсуждаем, кто и зачем 1.5 Г АП скушал. Про DLL и т.д.
На мелких проектах и студия 1.5 гига не кушает.
PD>Ох, что-то плохо верю.
Это не вопрос веры, это факт.
PD> Да и так — все равно хранят они в этом кеше что-то во внутреннем формате, не сами же исходники. И решарпер — он что, исходники парсит заново ?
Конечно.
PD>Кстати, если уж на то пошло — рефлектор же умеет восстановить код по IL. И довольно шустро.
Шустро, это когда один метод. А когда сотни тысяч?
AVK>>При чем. Без хидеров для ресолва приходится держать в памяти все символьные таблицы.
PD>И что ?
И 64К уже не хватит для программ соотв. размера.
PD>Ты попробуй напиши со всей своей командой программу, в которой 100000 имен
Решарпер вполне такая программа.
PD>Вообще-то отталкиваться нужно от ситуации, когда загружено то, что надо.
А надо может быть все.
AVK>>Разрабатывать несколько сред дорого и плохо с точки зрения маркетинга.
PD>Ну вообще-то до поры до времени VB был вполне отдельным от студии продуктом. И FoxPro тоже
По историческим причинам.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
PD>>Я не в теме, да, и не все так просто, но ведь 20-30 лет назад было не проще
AVK>Было. 20 лет назад просто не было аналогичных по функционалу IDE.
Разумеется. Но переменные (имена) были. Классы были. Компиляция была. И все это в 1 М укладывалось. Что-то я не верю, что понадобилось вдруг в 100 раз больше.
PD>>Я полагал, мы давно уже не про Решарпер говорим, а обсуждаем, кто и зачем 1.5 Г АП скушал. Про DLL и т.д.
AVK>На мелких проектах и студия 1.5 гига не кушает.
АП ? Или памяти ?
PD>>Ох, что-то плохо верю.
AVK>Это не вопрос веры, это факт.
Ну-ну.
PD>>Кстати, если уж на то пошло — рефлектор же умеет восстановить код по IL. И довольно шустро.
AVK>Шустро, это когда один метод. А когда сотни тысяч?
А что, сотни тысяч надо все сразу ? Если да — тут при любой структуре заткнешься. Но я все же думаю (с решарпером не знаком, но с аналогичным работал), все ограничивается не таким уж большим числом файлов и методов.
AVK>>>При чем. Без хидеров для ресолва приходится держать в памяти все символьные таблицы.
PD>>И что ?
AVK>И 64К уже не хватит для программ соотв. размера.
Не понял. Ты что, не понимаешь, что такое #include ? Их в принципе можно все исключить, но тогда придется вручную вставить их текст. Теоретически возможно (и даже практически можно только препроцессировать и вывести результат в файл — в VS). На скорость компиляции не повлияет (если не говорить о precompiled headers, но их тогда и близко не было), на размер таблиц тоже. Вообще ни на что не повлияет, кроме времени чтения файлов с диска.
PD>>Ты попробуй напиши со всей своей командой программу, в которой 100000 имен
AVK>Решарпер вполне такая программа.
Ну-ну...
На набор одного имени кладем 3 секунды. Имя же надо набрать, нет, тут же никто не поможет.
3 * 100000 = 300000 секунд = 83 часа = 3 месяца. Круглосуточно, без перекуров, обеда и сна. А при 8-часовом — почти год. Это только на описание всех имен. Программу будем набирать еще сколько времени ?
PD>>Вообще-то отталкиваться нужно от ситуации, когда загружено то, что надо.
AVK>А надо может быть все.
А вот когда надо будет, тогда и загрузим. И не все, а то, что надо будет когда надо будет . А потом выгрузим, и опять загрузим, когда надо будет. Всем этим методам 100 лет в обед.
AVK>>>Разрабатывать несколько сред дорого и плохо с точки зрения маркетинга.
PD>>Ну вообще-то до поры до времени VB был вполне отдельным от студии продуктом. И FoxPro тоже
AVK>По историческим причинам.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Но переменные (имена) были.
Да что ты уперся в эти имена? Там и без имен хватает что хранить. Типовой узел AST вполня модет содержать десятки указателей, чтобы навигация по дереву была максимально быстрой.
PD> Что-то я не верю, что понадобилось вдруг в 100 раз больше.
А я нигде и не писал, что в 100 раз больше понадобилось для компиляции.
AVK>>На мелких проектах и студия 1.5 гига не кушает.
PD>АП ? Или памяти ?
И того и другого.
AVK>>Шустро, это когда один метод. А когда сотни тысяч?
PD>А что, сотни тысяч надо все сразу ?
Для рефакторинга, интеллисенса и прочих подобных вещей — да.
PD> Но я все же думаю (с решарпером не знаком, но с аналогичным работал), все ограничивается не таким уж большим числом файлов и методов.
Твои теории не верны.
AVK>>И 64К уже не хватит для программ соотв. размера.
PD>Не понял. Ты что, не понимаешь, что такое #include ?
А ты понимаешь, что такое количество проходов компилятора, и почему раньше боролись за их минимизацию в том числе и урезанием фич языка, а современные компиляторы делают десятки проходов? Почему раньше во многих языках мейнстрима была такая вещь как forward declaration, а сейчас обычно обходятся без нее? Почему раньше библиотеки у многих языков имели специальный формат файла, а сейчас в качестве библиотек используются исполняемые файлы?
PD>>>Ты попробуй напиши со всей своей командой программу, в которой 100000 имен
AVK>>Решарпер вполне такая программа.
PD>Ну-ну...
Опять ну-ну. Это легко проверяется, благо вся метаинформация в сборках решарпера доступно. Посчитать суммарное количество имен типов, их членов и параметров совсем несложно.
PD>3 * 100000 = 300000 секунд = 83 часа = 3 месяца. Круглосуточно, без перекуров, обеда и сна.
И что? Решарпер не первый год существует, и команда не из одного человека состоит. Я конечно понимаю, что ты с таким никогда не сталкивался, но существуют проекты, которые намного больше решарпера.
AVK>>А надо может быть все.
PD>А вот когда надо будет, тогда и загрузим.
Видишь ли, разработчикам студии и решарпера надо рассчитывать на такие ситуации. Поэтому от того, что иногда это не надо, легче не становится.
PD>А потом выгрузим, и опять загрузим
Скажи, ты когда нибудь в жизни писал приложения с плагинами, в которых работающие плагины можно выгружать?
AVK>>По историческим причинам.
PD>Хорошие были причины
Нормальные. FoxPro, к примеру, МС купил готовым продуктом уже не первой версии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>Да что ты уперся в эти имена? Там и без имен хватает что хранить. Типовой узел AST вполня модет содержать десятки указателей, чтобы навигация по дереву была максимально быстрой.
Что-то мне кажется, что а) десятки — многовато и б) даже для десятка это всего лишь 40 байт.
PD>> Что-то я не верю, что понадобилось вдруг в 100 раз больше.
AVK>А я нигде и не писал, что в 100 раз больше понадобилось для компиляции.
А я и не говорил, что это ты писал. Просто те компиляторы работали в 64 К, а нынешние на 6.4 М работать ни за что не будут, да и на 64 М — не уверен.
PD>>А что, сотни тысяч надо все сразу ?
AVK>Для рефакторинга, интеллисенса и прочих подобных вещей — да.
Не знаю я решарпер, спорить не буду. Но интеллисенс есть был и в VS 5-6, для С++ ничем не хуже он тогда был, его, собственно, и не изменили. А работало все на 32-64 Мб физической ОП.
PD>> Но я все же думаю (с решарпером не знаком, но с аналогичным работал), все ограничивается не таким уж большим числом файлов и методов.
AVK>Твои теории не верны.
Ну это уже не аргумент.
AVK>>>И 64К уже не хватит для программ соотв. размера.
PD>>Не понял. Ты что, не понимаешь, что такое #include ?
AVK>А ты понимаешь, что такое количество проходов компилятора
Понимаю. В VС++ — один + второй от линкера (c2.dll).
>и почему раньше боролись за их минимизацию в том числе и урезанием фич языка
Никто ничего не урезал, насколько я помню, в том же ТурбоПаскале. Наоборот, расширили, а потом еще первый вариант ООП прикрутили , и все в 640 К.
>а современные компиляторы делают десятки проходов?
Откуда такая информация ? Ссылку дай, только не по экзотическим языкам.
>Почему раньше во многих языках мейнстрима была такая вещь как forward declaration а сейчас обычно обходятся без нее?
Отроду в Фортране не было. В C K&R не было (и до сих пор необязательна) — я прототип функции имею в виду. Где были-то ?
>Почему раньше библиотеки у многих языков имели специальный формат файла
Ну ты даешь. Формату COFF уже сто лет в обед.
>а сейчас в качестве библиотек используются исполняемые файлы?
Ты про статические библиотеки слышал ?
PD>>>>Ты попробуй напиши со всей своей командой программу, в которой 100000 имен
AVK>>>Решарпер вполне такая программа.
PD>>Ну-ну...
AVK>Опять ну-ну. Это легко проверяется, благо вся метаинформация в сборках решарпера доступно. Посчитать суммарное количество имен типов, их членов и параметров совсем несложно.
А любопытно бы.
PD>>3 * 100000 = 300000 секунд = 83 часа = 3 месяца. Круглосуточно, без перекуров, обеда и сна.
AVK>И что? Решарпер не первый год существует, и команда не из одного человека состоит. Я конечно понимаю, что ты с таким никогда не сталкивался, но существуют проекты, которые намного больше решарпера.
Я с таким не сталкивался. Слава богу
PD>>А вот когда надо будет, тогда и загрузим.
AVK>Видишь ли, разработчикам студии и решарпера надо рассчитывать на такие ситуации. Поэтому от того, что иногда это не надо, легче не становится.
А все же, почему нельзя загружать и выгружать по мере надобности ?
PD>>А потом выгрузим, и опять загрузим
AVK>Скажи, ты когда нибудь в жизни писал приложения с плагинами, в которых работающие плагины можно выгружать?
Если бы они все одновременно работали, то я бы согласился. Но реально работают только некоторые. Остальным можно послать команду "стоп", потом выгрузить, сохранив состояние, если надо. Все это решаемо. Есть же даже выгрузка драйверов 0 кольца, а это тебе не плагин.
AVK>>>По историческим причинам.
PD>>Хорошие были причины
AVK>Нормальные. FoxPro, к примеру, МС купил готовым продуктом уже не первой версии.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что-то мне кажется, что а) десятки — многовато
Ну, что там тебе кажется, это уж ты сам.
PD> и б) даже для десятка это всего лишь 40 байт.
Только вот узлы для рефакторинга нужно создавать на каждый токен.
PD>А я и не говорил, что это ты писал. Просто те компиляторы работали в 64 К, а нынешние на 6.4 М работать ни за что не будут, да и на 64 М — не уверен.
Зато они работают быстрее и качественнее.
AVK>>Для рефакторинга, интеллисенса и прочих подобных вещей — да.
PD>Не знаю я решарпер, спорить не буду. Но интеллисенс есть был и в VS 5-6, для С++ ничем не хуже он тогда был
Речь не про С++. В С++ нормального интеллисенса и рефакторинга просто не сделать ввиду дизайна языка.
AVK>>Твои теории не верны.
PD>Ну это уже не аргумент.
Для аргумента попробуй сперва свои теории хоть как то обосновать. А то получается очередное требование доказать несуществование Летающего Макаронного Монстра.
AVK>>А ты понимаешь, что такое количество проходов компилятора
PD>Понимаю. В VС++ — один + второй от линкера (c2.dll).
Все таки не понимаешь. Книжку с драконом читал PD>Никто ничего не урезал, насколько я помню, в том же ТурбоПаскале.
Неверно ты помнишь. Грамматика ТурбоПаскаля специальным образом заточена под однопроходную компиляцию, как и формат tpu файлов.
>>а современные компиляторы делают десятки проходов?
PD>Откуда такая информация ? Ссылку дай, только не по экзотическим языкам.
Фортран настолько убог, что ему это не нужно
PD> В C K&R не было (и до сих пор необязательна) — я прототип функции имею в виду. Где были-то ?
Простой вопрос — всегда ли можно обойтись без forward declaration?
>>а сейчас в качестве библиотек используются исполняемые файлы?
PD>Ты про статические библиотеки слышал ?
Т.е. компилятору С достаточно одной только dll, чтобы скомпилировать программу с ее использованием?
AVK>>Опять ну-ну. Это легко проверяется, благо вся метаинформация в сборках решарпера доступно. Посчитать суммарное количество имен типов, их членов и параметров совсем несложно.
PD>А любопытно бы.
Ну вот и займись.
PD>А все же, почему нельзя загружать и выгружать по мере надобности ?
Ты меня вообще читаешь? Неважно, что будет на игрушечных ситуациях, важен максимально плохой случай. Ты там много флагом по поводу качества размахивал: что ты думаешь по поводу качества программы, в которой попытка использовать весь функционал в один момент приводит к ее вылету?
Пакеты в студии, кстати, грузятся по требованию. Но далеко не всегда это можно обеспечить чисто логически. Ряд пакетов обязаны стартовать в момент загрузки солюшена.
AVK>>Скажи, ты когда нибудь в жизни писал приложения с плагинами, в которых работающие плагины можно выгружать?
PD>Если бы они все одновременно работали, то я бы согласился. Но реально работают только некоторые. Остальным можно послать команду "стоп", потом выгрузить, сохранив состояние, если надо. Все это решаемо. Есть же даже выгрузка драйверов 0 кольца, а это тебе не плагин.
Не вижу ответа на заданный вопрос.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
Здравствуйте, Pavel Dvorkin, Вы писали:
>>а сейчас в качестве библиотек используются исполняемые файлы? PD>Ты про статические библиотеки слышал ? AVK>Т.е. компилятору С достаточно одной только dll, чтобы скомпилировать программу с ее использованием?
Павел, видимо, имеет в виду, что статическая линковка до сих пор является достаточно широко используемым способом работы с библиотеками. Статическая означает, что библиотека имеет тот самый "специальный формат", о котором ты говоришь, и в итоге у тебя получается один исполнимый файл без внешних зависимостей.
А для того, что "скомпилировать программу с одной только dll" проблем тоже как-то не видно, достаточно, чтобы для этой DLL импорт-директивы были прописаны именно в том виде, в котором их понимает конкретный компилятор.
Просто, честно говоря, твое заявление про то, что сейчас "в качестве библиотек используются исполняемые файлы" относится исключительно к дотнету. Есть ведь не только дотнет. Еще куча ниш есть на рынке. Вон на эпловских платформах вообще Objective C рулит (неплохой, кстати, язык).
Раньше тоже было можно, но это было не всегда удобно (и не всегда возможно, если речь о хедер-онли библиотеках, вроде того же буста). В дотнете это стало распространенным вариантом, благодаря хотя бы дизайну языков. Если б в том C# были бы шаблоны, хрен бы ты в качестве библиотек исполнимые файлы использовал.
Здравствуйте, vdimas, Вы писали:
AVK>>Не то слово. Вот уж кому 64 бита нужно, так это студии.
V>А если прилично кода студии теперь на дотнете, то почему бы не перекомпилировать в 64? Самое время.
Вопрос не ко мне.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
PD>>А я и не говорил, что это ты писал. Просто те компиляторы работали в 64 К, а нынешние на 6.4 М работать ни за что не будут, да и на 64 М — не уверен.
AVK>Зато они работают быстрее и качественнее.
Насчет качественее — не спорю. Насчет быстрее... Давай сравним. ТурбоПаскаль 1.0 на Ямахе с тактовой частотой 2 МГц и памятью в 64К компилировал программу в 1000 строк несколько секунд. Сколько времени надо, чтобы откомпилировать программу размером в 1 млн строк на процессоре в 2 Ггц ? Очевидно, тоже несколько секунд. Давай сюда этот компилятор!
AVK>Речь не про С++. В С++ нормального интеллисенса и рефакторинга просто не сделать ввиду дизайна языка.
+1 насчет рефакторинга. Интеллисенс там есть, хоть и не такой.
PD>>Ну это уже не аргумент.
AVK>Для аргумента попробуй сперва свои теории хоть как то обосновать. А то получается очередное требование доказать несуществование Летающего Макаронного Монстра.
Это еще менее аргумент. А обоснования я приводил не раз в этом нашем треде, путем сравнения с компиляторам прошлых времен. Одно из них выше.
AVK>>>А ты понимаешь, что такое количество проходов компилятора
PD>>Понимаю. В VС++ — один + второй от линкера (c2.dll).
AVK>Все таки не понимаешь. Книжку с драконом читал
Ну не понимаю — и не надо. До сих пор вроде как понимал, и все так же понимали
Ну что же, если в C# это нужно — на здоровье. В С++ — нет.
PD>>Отроду в Фортране не было.
AVK>Фортран настолько убог, что ему это не нужно
PD>> В C K&R не было (и до сих пор необязательна) — я прототип функции имею в виду. Где были-то ?
AVK>Простой вопрос — всегда ли можно обойтись без forward declaration?
Прототипы функций в С необязательны. Что же касается
struct A {
struct B* ptr;
};
struct B {...};
то да, предописание необходимо, но в нем нельзя упоминать поля. Вот так можно
>>>а сейчас в качестве библиотек используются исполняемые файлы?
PD>>Ты про статические библиотеки слышал ?
AVK>Т.е. компилятору С достаточно одной только dll, чтобы скомпилировать программу с ее использованием?
Ты хоть представление имеешь о том, как компиляция в С/C++ идет ? Компилятору С не надо никаких DLL вообще, поскольку он с ними работать не умеет (за исключением #import, но это OLE). Он компилирует из .c в .obj. Линкеру в С++ тоже никаких DLL не надо, потому что поскольку он с ними работать не умеет. Ему нужны .lib файлы, или статические либы, или библиотеки импорта. В общем, собрать EXE, не имея требуемых для него DLL можно, более того, есть эти DLL или нет — ни на что не влияет при сборке EXE. При запуске, конечно, все DLL вынь да положь.
AVK>>>Опять ну-ну. Это легко проверяется, благо вся метаинформация в сборках решарпера доступно. Посчитать суммарное количество имен типов, их членов и параметров совсем несложно.
PD>>А любопытно бы.
AVK>Ну вот и займись.
PD>>А все же, почему нельзя загружать и выгружать по мере надобности ?
AVK>Ты меня вообще читаешь? Неважно, что будет на игрушечных ситуациях, важен максимально плохой случай. Ты там много флагом по поводу качества размахивал: что ты думаешь по поводу качества программы, в которой попытка использовать весь функционал в один момент приводит к ее вылету?
Думаю, это просто означает, что не очень хорошо продуман функционал. Потому что невозможно его использовать целиком одновременно.
Вот тебе простой пример — виртуальная память. Максимально плохой случай в твоем понимании — это когда все страницы процесса должны быть в ОП. И всех процессов. Но этого никто не допустит просто-напросто, поскольку память не резиновая. Часть страниц в ОП, часть в свопе или mmf. Живем.
AVK>Пакеты в студии, кстати, грузятся по требованию. Но далеко не всегда это можно обеспечить чисто логически. Ряд пакетов обязаны стартовать в момент загрузки солюшена.
Да, знаю. Именно они и ругаются, если что не так.
AVK>>>Скажи, ты когда нибудь в жизни писал приложения с плагинами, в которых работающие плагины можно выгружать?
PD>>Если бы они все одновременно работали, то я бы согласился. Но реально работают только некоторые. Остальным можно послать команду "стоп", потом выгрузить, сохранив состояние, если надо. Все это решаемо. Есть же даже выгрузка драйверов 0 кольца, а это тебе не плагин.
AVK>Не вижу ответа на заданный вопрос.
Ну что же, отвечу формально. Программы с DLL, которые загружаются и выгружаются по мере надобности, я писал. Плагины я не писал вообще.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А для того, что "скомпилировать программу с одной только dll" проблем тоже как-то не видно, достаточно, чтобы для этой DLL импорт-директивы были прописаны именно в том виде, в котором их понимает конкретный компилятор.
Маленькое уточнение. Для VC++ — не импорт-директивы, а библиотека импорта, отдельный файл. Обычно прилагается к DLL, но при необходимости может быть сгенерирован по DLL
Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>>Зато они работают быстрее и качественнее. PD>Насчет качественее — не спорю. Насчет быстрее... Давай сравним. ТурбоПаскаль 1.0 на Ямахе с тактовой частотой 2 МГц и памятью в 64К компилировал программу в 1000 строк несколько секунд. Сколько времени надо, чтобы откомпилировать программу размером в 1 млн строк на процессоре в 2 Ггц ? Очевидно, тоже несколько секунд. Давай сюда этот компилятор!
Очевидно, что тот компилятор с памятью в 64К может и не скомпилировать 1 млн. строк вообще хотя бы ввиду отсутствия этой самой памяти.
О какой-то линейной зависимости можно говорить на совершенно простых языках, и то, я даже не знаю языка который не потребовал бы каких-либо внутренних структур.
Да и с оптимизациями в ТурбоПаскале 1.0 было совсем туго.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Насчет качественее — не спорю. Насчет быстрее... Давай сравним. ТурбоПаскаль 1.0
Сравнивать надо компиляторы одинаковых языков.
PD>+1 насчет рефакторинга. Интеллисенс там есть, хоть и не такой.
Вот именно что тоже убогий.
AVK>>Неверно ты помнишь. Грамматика ТурбоПаскаля специальным образом заточена под однопроходную компиляцию, как и формат tpu файлов.
PD>Ну слава богу, хоть ТурбоПаскаль однопроходной. А VC++ — сколько проходов все же ?
Потому что С++ существенно более старый язык.
PD>то да, предописание необходимо
Вот именно. А в Java и C# такой необходимости нет, там forward declaration отсутствует как класс.
PD>Но из этого, в общем, мало что следует.
Из этого следует то, что язык специально заточен под минимальное количество проходов. А минимальное количество проходов нужно как раз чтобы компилятору хватало малого объема памяти.
PD>Ты хоть представление имеешь о том, как компиляция в С/C++ идет ?
Павел, если есть желание заняться пенисометрией, то не советую. У меня все равно длиннее. Ты не у меня пробелы в знаниях ищи, а подумай, как это связано с лимитом потребления памяти.
PD>Думаю, это просто означает, что не очень хорошо продуман функционал.
Нет, это означает что программа не качественна и не полностью удовлетворяет требованиям.
PD> Потому что невозможно его использовать целиком одновременно.
Возможно.
AVK>>Пакеты в студии, кстати, грузятся по требованию. Но далеко не всегда это можно обеспечить чисто логически. Ряд пакетов обязаны стартовать в момент загрузки солюшена.
PD>Да, знаю.
Ну так вот в основном эти пакеты память и жрут.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>>>Зато они работают быстрее и качественнее. PD>>Насчет качественее — не спорю. Насчет быстрее... Давай сравним. ТурбоПаскаль 1.0 на Ямахе с тактовой частотой 2 МГц и памятью в 64К компилировал программу в 1000 строк несколько секунд. Сколько времени надо, чтобы откомпилировать программу размером в 1 млн строк на процессоре в 2 Ггц ? Очевидно, тоже несколько секунд. Давай сюда этот компилятор! F> Очевидно, что тот компилятор с памятью в 64К может и не скомпилировать 1 млн. строк вообще хотя бы ввиду отсутствия этой самой памяти.
Я не про память , а про время писал. Ускорили процессор в 1000 раз — давайте в 1000 раз большую скорость.
F> О какой-то линейной зависимости можно говорить на совершенно простых языках, и то, я даже не знаю языка который не потребовал бы каких-либо внутренних структур. F> Да и с оптимизациями в ТурбоПаскале 1.0 было совсем туго.
Весь институт одновременно сидел... 
