Если вы считаете, что они перестали существовать - вы глубоко ошибаетесь.
Нет, не считаю.
Нормальные архитектуры и разрабатываются в соответствии с возможностями железа
Чушь. Нормализация не должна быть привязана к железу. Для каждого языка программирования есть свои способы оптимизации, для методов программирования - тоже. Жесткая привязка к железу допустима только на микроконтроллерах.
И написано это было исключительно для того, чтобы показать автору вопроса, что можно и одной строчкой нарушить и архитектуру и любовь заказчика
Тогда непонятна тяга к повсеместному переходу на NET и отказу от асма и с.
Чушь. Нормализация не должна быть привязана к железу.
Цель нормализации - именно ускорение работы программы, что в свою очередь ведет к поддержке менее производительного железа. Я говорю именно об этом.
О чем и было замечено что это мусорный код.
Мусорный, но возможный в руках новичков!
Впрочем думаю спор уже потерял смысл, так как по основной идее мы видимо сразу не поняли друг друга. Я не предлагал использовать этот код, как вы, видимо, подумали. Думаю и так ясно, что если программа рассчитана на современное железо с оперативой от 4 гигов, то 4 байта не спасут. Но могут возникнуть и другие ситуации - терминальные подключения (с ограниченным выделением памяти), старые компы и др.
Почему обязательно мусорный? Почти любая программа, построенная на динамическом программировании содержит большой многомерный массив. Например, int dp[1 << 20][20][20] - полутора гигов как не бывало.
Так я поясню.
Речь идет не о том сколько массив занимает в памяти, а о том что уже на этапе декларации объявляется статический массив фиксированных строк, причем немалого размера и, судя по всему, на глобальном уровне.
И я не представляю ни одной ситуации когда такое "решение" может быть оправдано. Разве что если целью ставить потребление системных ресурсов...
В общем, я в своем отделе на Code Review такой номер бы не пропустил.
Речь идет не о том сколько массив занимает в памяти, а о том что уже на этапе декларации объявляется статический массив фиксированных строк, причем немалого размера и, судя по всему, на глобальном уровне.
Ну для начала, речь шла именно об объеме занимаемой памяти. Во вторых т.е. ты точно уверен, что такое невозможно?
статический массив фиксированных строк, причем немалого размера
А судишь ты исходя из того, что тебе так хочется
Rascal,
куда важнее структуры данных, базы данных, работа с файлами
Т.е. ты предлагаешь все операции в ОЗУ перенести в базу данных и на ЖД. Очень интересное предложение. Видимо быстродействующих приложений существовать не должно - Rascal не хочет быстроты
1) Первых пентиумов НЕ ОСТАЛОСЬ. Вторых и тертьих тоже.
2) Память вообще ничего не стоит. Недавно поставил себе +4 гб (в сумме 6) - обошлось меньше 50 баксов. Сам офигел.
3) Говорить о VB6 серьезно - это смешно. Говорить о каких-то там оптимизациях в VB6 серьезно - это уже похоже на неврологические проблемы!
4) Dim HAHAHA(1000) As String * 64000 - это 64 (или 128?) МБ. Этого никто даже не заметит, хотя, безусловно, делать так не нужно (хотя можно если есть необходимость).
5) А что в VB6 бывают фиксированные стркои 64000?
VBD пишет:
SteelBrand, ты слишком сильно опускаешь VB6.
VBD, не хочу разрушать твою детскую мечту, но этот язык мертв. И опустить его невозможно - потому что он уже и так лежит на дне.
Я понимаю, ты потратил несколько лет для того чтоб научиться делать простейшие вещи в VB6, получил какие-то знания. И боишься расстаться с этими знаниями.
Нужно просто забыть про этот VB6 и начать изучать реально крутые вещи. .NET, Java.
этот язык мертв. И опустить его невозможно - потому что он уже и так лежит на дне.
Steel Brand, не стоит делать столь категоричные заявления только на основании того что ты этим языком не пользуешься. Это непрофессионально. Могу тебя уведомить о том что на VB6 до сих пор пишутся и поддерживаются серьезные коммерческие системы.
Софт не сводится к одним только квейкам и крайсисам...
Arvitaly пишет:
Т.е. ты предлагаешь все операции в ОЗУ перенести в базу данных и на ЖД. Очень интересное предложение. Видимо быстродействующих приложений существовать не должно - Rascal не хочет быстроты
Ну вообще-то хранение данных в базе данных это единственное разумное решение (кстати именно поэтому базы данынх называются базами данных - потому что в них хранятся данные).
В самом приложении держать даные нет смысла. Хотя бы потому, что усложняется логика. В памяти данные - следовательно, программа имеет какое-то свое внутреннее состояние, значит за ним нужно следить, поддерживать его актуальность и т.п.
В Windows-приложениях, конечно, так часто приходится делать, чтоб обеспечить достаточную интерактивность интрфейса, особенно когда данные находятся на удаленной машине.
Впрочем именно за это я люблю Web, классическая единица работы - запросил нужные данные из БД, скинул клиенту.