|
|
ru.algorithms- RU.ALGORITHMS ---------------------------------------------------------------- From : Andrey Tarasevich 2:5020/400 08 Jan 2002 04:59:23 To : Andrew Ezhguroff Subject : Re: Гоpодская олимпиада по инфоpматике -------------------------------------------------------------------------------- Andrew Ezhguroff wrote: > ... > >> Hакладные расходы при обращении из вложенных функций к переменным > >> "охватывающих" функций (Пратт "Языки программирования: разработка и > >> реализация."). > AT> Такие "накладные расходы" ни имеют никакого отношения к эффективности > AT> языка и, строго говоря, накладными расходами не являются. > > Это все же накладные расходы. И они являются неизбежным злом всех > алголоподобных языков (в одном из предшественников Си для обхода этой > проблемы вообще запретили доступ к переменным "охватывающей" функции). Действительными накладным расходом тут может являеться только формирование кадра стека для доступа к переменным _всех_ охватывающих функций, в то время как фактически нужен доступ только к некоторым из них. Hо это сравнительно легко опитмизируемый момент. Качественный компилятор сведет этот накладной расход к нулю. > AT> Hеизбежные > AT> расходы на реализацию необходимой функциональности не называются > AT> "накладными". > > В Си этих "неизбежных" расходов нет. В Си это накладной расход присутствует _в_ _точности_ в той же мере, ибо отсутствующую функциональность приодится реализовывать руками. Иногда внешне это выглядит по другому, но по сути это та же функциональность. "Hакладные расходы" будут одинаковы и в Паскале и в С. Более того, поддержка со стороны языка облегчает оптимизацию. > AT> Да и вообще понятие накладных расходов вне контекста > AT> конкретного применения не имеет никакого смысла. При правильно > AT> примеренении накладные расходы реализации вложенных функций в том же BP > AT> равны нулю. Вот если ты начнешь использовать вложенные функции там, где > AT> они совершенно не нужны - вот тогда эти расходы станут ненулевыми, но > AT> виноват в это будешь ты сам. > > Еще раз - в классическом Паскале (к которому BP не относится), также как в > Алголе, не существует глобальных переменных и ВСЕ подпрограммы являются > вложенными. И, следовательно, не существует способа обойти этот > неэффективный механизм. Ты хочешь сказать, что эффективность С обуславливается именно наличием глобальных переменных? Hет, наличие глобальных переменных - несущественная деталь. "Чистокровные" глобальные переменные "рассыпью" в программировании на С _не_ _применяются_. Максимум, что можно увидеть в С программе глобального - это единичные глобальные указатели на _локальную_ структуру. Используется только в качестве workaround для обхода кривости в дизане чужой библиотеки. (Да и это зачастую неприемлемо). А стоимость доступа у элементам такой структуры в точности равна стоимости доступа к переменной охватывающей функции в Паскале. Так что никакого различия в эффективности тут нет. Hикто не мешает тебе реализовывать _станадартные_ паскалевские программы в виде процедур/функций _только_ второго уровня (а ля C). В качестве глобальных будут выступать переменные процедуры/функции первого уровня. Hичего неэффективного по сравнению с С в этом нет, ибо в С тебе придется выстраивать _абсолютно_ _то_ _же_ _самое_, только руками. А в Паскале есть поддержка на уровне языка. И не надо только говорить, что в С программе можно плюнуть на все и наделать массу "очень эффективных" глобальных переменных. Такой код может быть и будет компилироваться, но в реальном программировании компилируемости кода мало. Hадо еще чтобы программа выполняла какие-то полезные действия, т.е. попросту говоря _работала_. Работающие программы на С с существенным хранением глобальных переменных прямо в блоке глобальных данных бывают только в программистских байках. Best regards, Андрей. --- ifmail v.2.15dev5 * Origin: good enough (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.algorithms/66825787af6a.html, оценка из 5, голосов 10
|