- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
string=(char*)malloc(N);
k=fread(string,sizeof(char),N,f);
while (k==N)
{
free(string);
N=N*2;
rewind(f);//возращает в начало файла
string =(char*)malloc(N);
k=fread(string,sizeof(char),N,f);
}
fclose (f);
> N=N*2;
> rewind(f);
> string =(char*)malloc(N);
Не рассказывали студентам про realloc() или хотя бы про memcpy()?
P.S. Если это Си, то каст в (char*) тоже не нужен.
Ни проверки кода возврата, ни попытки определения размера файла...
Ну это уже ССЗБ. Для таких файлов идиома "засосать файл целиком в оперативу", имхо, непригодна даже если ее правильно реализовать... Тут уже надо думать в сторону потоковой обработки или маппинга.
> malloc может обломаться
> проверки кода возврата
Ну кто же в лабах проверяет коды возврата? ;) Тут вон даже в энтерпрайзненькой жабе умудрились просрать ошибку записи (см. #14254).
Нас в своё время заставляли проверять абсолютно все коды возврата, в том числе из malloc. И вручную освобождать всю выделенную память, несмотря на то, что при завершении процесса ОС всё равно её освободила бы.
И это хорошо. Нас не заставляли, работает на контрольных примерах и ладно :(
> при завершении процесса ОС всё равно её освободила бы.
Ну-ну. А если процесс завершится через 360 дней, на следующей профилактике железа? :)
я как уже тогда имел опыт программирования, так мне было легко, а однокурсники страдали.
я тоже страдал, но по другому поводу: это был курс VB6, а там много неудобств было.
Тут скорее про реентерабельность и чистоту говорить надо. Сферические 360 дней в вакууме нечасто встречаются, а вот когда не помнишь, как использовать свою функцию, чтобы нигде не бомбануло, начинаешь писать чуть более прямой код.
Проблема скорее в том, что код может использоваться как модуль.
Это же не демоны были, где было чему течь, а достаточно простые консольные утилитки.
Тоже верно ;) Но я тут о случаях, когда почему-то все-таки надо писать именно на нем.
Мне больше нравится вариант, когда все что можно делается на высокоуровневом языке вроде питона, а на сях пишутся только расширения для того, что этот высокоуровневый язык не осилил (вроде производительности в узких местах). Почти всю работу с памятью можно будет спихнуть на высокоуровневый язык. Хотя я этот вариант и не проверял.
Может он и сложнее, но граблей в нем все-таки поменьше, да и писать на нем легче.
Хотя смотря что писать ;)
Я о чистом Ц. Ц (не кресты!) как язык очень прост. Сложны приемы работы с ним и грабли.
- Мелкие функции для высокоуровневых языков (которые на высоком уровне не получается запилить из-за скорости или нативности).
- Рантаймы этих самых языков (Ну не на асме же их писать в конце концов).
- Прошивки для контроллеров.
- Ядра операционок и драйвера к ним.
Хотя вот драйверы, имхо, уже пора переводить на что-то более высокоуровневое, т.к. сейчас они во-первых слишком всемогущи (могут делать абсолютно всё, а не только управлять своей железкой), а во-вторых слишком ответственны (могут наебнуть весь комп при малейшей ошибке). Singularity от M$ была интересным проектом, идущим в эту сторону, но ее вроде как забросили.
>т.к. сейчас они во-первых слишком всемогущи (могут делать абсолютно всё, а не только управлять своей железкой),
А зачем? Если хуйня случится - во-первых, ось уронят, во-вторых, отлаживать тяжелее.
Да 99% прикладников даже с первым никогда не столкнутся ;)
> мы же о прикладных программах говорим, да
Нет ;) Ну иначе зачем бы я упоминал прошивки, дрова и т.п.
> Если хуйня случится - во-первых, ось уронят, во-вторых, отлаживать тяжелее.
Ну что поделать, вот так вот и мучаются. В основном, имхо, из-за производительности.
>Нет ;)
А я - да.
>В основном, имхо, из-за производительности.
А в чем этот прирост заключается, чтобы так жертвовать стабильностью?
В том, что если сейчас сделать по процессу, крутящемуся в юзермоде, на драйвер (а сейчас других способов изоляции нет), то будет довольно дорогая передача данных между ними (сейчас драйверы практически напрямую, без переключения контекстов, общаются друг с другом и с железом).
И не говори. Питухи. стоп ошибка 000000 кококо пришло время переустанавливать шиндовс.
D не вкушали? вроде бы тот же С, но с человеческим лицом
Или очередная вариация на тему Си-с-классами?
Можно просто погуглить Digital Mars или DMD/gdc/ldc.
А визуальный дизайнер форм есть у него? С визуальным дизайнером учить язык куда проще.
пока вам угодно зависеть от .NET фреймворка, все хорошо.
Потому, что лучезарная фея в белом одеянии только что вероломно улыбнувшись вколола тебе аминазин а также на тебе висит смокинг аж на несколько десятков размеров больше.
Сишарп/жава же. Фреймверк - это не сторонняя зависимость, хотя для жавы по любому придется таскать с собой commons.
в kdevelop вроде есть плагин, в mono-develop видел
вроде ещё есть плагин в idea
Но в D есть GC :)
Go компилится в натив, в нём есть гц, нормальная стандартная библиотека, корутины и каналы из коробки.
хм.
з.ы. давно хотел сказать, аватара напоминает собаку, что пытались пристрелить в фильмах "Нечто"
Уж лучше, чем поделие тёмного разума александреску с неясными перспективами.
Go проектировали Томпсон и Пайк, а эти ребята знают толк в concurrency.
Енто ты про Design Patterns?
Плюсы вообще не трогал и не собираюсь
А как разрешать конфликты?
Параноики могут приписывать в конец метки ууид.
All GNU/Linux filesystems (including swap and LUKS headers of raw encrypted devices) support UUID. FAT and NTFS filesystems (fat and windows labels above) do not support UUID, but are still listed in /dev/disk/by-uuid with a shorter UID (unique identifier)
Запусти blkid, увидишь их.
Я вот сейчас как раз размышлял по этому поводу.
Допустим, я пишу класс, который упаковывает и шифрует несколько входных потоков в один выходной поток. В общем случае оба потока не умеют в перемотку. Поэтому я не могу ни замерить длину заранее, ни перемотать выходной поток и вписать ее в заголовок. Читать весь поток в память тоже не вариант, т.к. она не резиновая.
В мою дурную голову пришли три решения:
1) Писать длину не до блока данных, а после (аля trailer в gzip). Засада в том, как это потом распаковывать.
2) Юзать что-нибудь в духе HTTP'шного chunked encoding. Есть оверхед, но он контрится достаточно большим буфером.
3) Делать отдельный индексный файл, в котором лежат офсеты. Неудобство в лишнем файле.
Пока склоняюсь ко второму варианту, но может есть более разумные решения?
Но зачем? Было бы неплохо, если бы нам си преподавали, но ручное управление памятью и коды возврата таки кал.
А Вы не боитесь, что студенты рассердятся и устроят Вам темную?
Кто явится завтра на зачет с непобритым лобком и попкой, тот получит кол!!
© Анальный учитель.