У Паскалі немає функції копіювання файлів?
Адже використання викликів WinApi суперечить концепції мультіплатформенності мови.
Дик адже таку функцію написати - хвилина роботи.
мені здається розробникам компілятора можна було б її ввести, як "посилання" на виклик ВІНАП, щоб при переході на іншу платформу її поміняли на відповідний виклик апі тієї платформи. В результаті текст проги не як і належить комптліруемим мов не прийдеться правити.
Написати то можна, але швидкість IMHO постраждає, тому що буфер твоєї проги і буфер ядра OS працюють явно не однаково :-(.
При чому тут компілятор? Це RTL. Компілятор взагалі не зобов'язаний мати функцій роботи з файлами.
> Написати то можна, але швидкість IMHO постраждає, тому що буфер твоєї
> Проги і буфер ядра OS працюють явно не однаково :-(.
Так адже RTL - і так надбудова над API. Пишеш GetMem, маєш на увазі VirtualAlloc (в Delphi) або HeapAlloc (в FPC / Win32). А якщо (що на самом деле) ситуація складніша і все-таки працює свій менеджер купи, так це заради того, щоб зробити роботу з пам'яттю більш ефективною в порівнянні з роботою на API. Я колись порівнював час роботи програм, в циклі робили або GlobalAlloc, GlobalLock, GlobalUnlock, GlobalFree, або GetMem, FreeMem - так виграш був аж ніяк не у WinAPI. Те ж, IMHO, - і з файловими операціями.
2Goblin (26.12.03 12:57) [6]:
Пропоную перевірити.
> Чи не зобов'язаний, але Паскаль має підтримку файлів, може і зайве.
ІМХО, дуже навіть зайве. Сильно замутняет розуміння при вивченні мови.
Я думаю введено було, щоб не мати залежності від ОС
Результати 5 прогонів:
981 1202
911 982
971 1042
962 1031
981 1072
l: = filesize (f1);
getmem (buf, l);
Тобто Ви зчитуєте в буфер весь файл? А якщо він 700Мб (фільм)?
а робота з файловими потоками платформозавісіма.
> Адже використання викликів WinApi суперечить концепції
> Мультіплатформенності мови
Так само як і взагалі використання поняття "файл".
Пам'ять: 0.76 MB
Час: 0.038 c