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

GZ>>>Влад. Только не надо говорить что все программирование ограничивается бизнес-приложениями.
VD>>Я где-то такое говорил?
GZ>Ты такое недвусмысленно подразумевал.

Телепат?

VD>>Одно дело знать, что такое блок памяти, а другое думать только ими.
GZ>Неее. Я до сих пор думаю ими.

Слабо верится.

GZ>И это мне помогает понять язык. И тебе тоже.

И как тебе помогает понять скажем идиому интерфейсов раздумья о блоках памяти? Ну, или как это тебе помогает понимать паттерны проектирования вроде Посетителя?

GZ> А особенно помогает работать с массивами. И смотреть чтобы не было копирования больших данных. И тут абстракция не поможет. Здесь нужно иметь привычку делать так, чтобы потом кардинально не переделывать. Это в большей степени не проблема дизайна, а алгоритмическая проблема. Хотя меру тоже надо знать.

Я такой проблемы вообще не встречал. По-моему, и так понятно, что чем больше данных ты бестолку копируешь, тем болше времени и памти таратися зря.

GZ>Мы с тобой(судя по возрасту) плоды такого обучения. И я рад что прошел школу 286 процессора и CGA экрана.

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

Так вот я осознанно предалел (и продолжаю преодалевать) психологические проблемы борьбы за производительность. А некоторые товарищи даже не задумываются над необходимостью делать это. И то что эти товарищи старше лет на 10 нисколько их не оправдывает.

GZ> Очень обучает думать. Так кто там мерял скорость GDI+?

Ничего. Я потом опубликую результаты измерений и боюсь многие будут удивлены в какие мифы они верили. Забегая вперед скажу, что GDI+ не так тормозна как его многие описывают. При грамотном применении эта библиотека на сильно медленнее чем GDI.

GZ>Правильно действовать легко научить. Правильно думать — значительно труднее. И для системы алгоритм+доступные_ресурсы — нужно учиться думать.

Я не вижу потуги думать у учителя. И почти уверен, что именно этому в превую очередь научатся его ученики. Они всю жизнь будут вызимать биты из байтов. Ведь сломать привычку не так то просто. Любой кто бросал курить или переучивался печатать вслепую поймет о чем речь.

GZ>Думать абстракциями — также нужно учить. То же очень сложная штука. Но это и не обозначает отмену вышеописанного.

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

Ведь езжу понятно, что быстрее выделения памяти в стэке быть ничего не может. Но это ведь не приводит разумных программистов к отказу от использования тех же строковых классов?

Я вижу следующую цепочку рассуждений.

Программы жрут больше ресурсов чем могли бы...
Надо писать так чтобы использовать минимально достаточный объем ресусров...
Абстракции зачастую увеличивают объем используемых ресуросв...
Так откажемся от абстаркций и будем долбить все в стиле С.

При этом, правда, приводятся примеры с использованием тормознеших sprintf-ов, ну, да сути дела это не меняет.

Итог один — формирование стойкой неприязни к абстракциям в следствии погони за битами.