malloc и использование динамической памяти
Ибо с самого начала надо учиться делать правильно.+1
А то потом будет труднее переучиваться.
Вот так люди привыкают, что все всегда работает, что malloc и fopen всегда возвращает не NULL...
А если вдруг ихние программы попытаться запустить на другой машине, с другой архитектурой, с другой OC, то тогда можно выяснить, что и у int-а бывает разный размер, что функции getch просто нету, ровно как и библиотеки <conio.h>
Когда malloc возвращает NULL, обычно ничего исправить уже нельзя. А сложность программы, которая сама использует malloc вырастает в разы.
По крайней мере, можно и нужно культурно выйти, а не упасть с сегфолтом.
это нужно добавить в букварь программирования!Вот так люди привыкают, что все всегда работает, что malloc и fopen всегда возвращает не NULL...Когда malloc возвращает NULL, обычно ничего исправить уже нельзя. А сложность программы, которая сама использует malloc вырастает в разы.
> Когда malloc возвращает NULL, обычно ничего исправить уже нельзя
правильная программа просто откатывает выполнение последнего действия
правильная программа просто откатывает выполнение последнего действия
Вот это уж точно. Необработка malloc == NULL и связанное с этим тихое падение программы с прелестями типа несохраненных результатов итп --- хуже не придумаешь.
правильная программа не просто откатывает выполнение последнего действия, но и предупреждает юзера об ошибке 
И дает адресок магазина, где ему еще памяти прикупить
это само собой.
это уже делает нормальная программа, а не только правильная.
это уже делает нормальная программа, а не только правильная.
Нет-нет, сама заказывает память через инет с доставкой!
Нет-нет, сама заказывает память через инет с доставкой!Ну если только по кредитке Билла Гейтса.
Когда malloc возвращает NULL, обычно ничего исправить уже нельзя. А сложность программы, которая сама использует malloc вырастает в разы.смысл этой фразы от меня ускользает
Что значит "А сложность программы, которая сама использует malloc вырастает в разы."?
Если программа "сама" не использует malloc, то проблем с malloc-ом не возникнет по определению, а если C программист (не путать с C++ программистом) решил воспользоваться прелестями динамического выделения памяти, то уж пусть изволит проверять возвращаемое значение malloc/calloc/realloc, иначе он долб или раздолбай (что для автора промышленного софта еще хуже чем долб, а для учащегося простительно, но нежелательно).
PS: Когда malloc возвращает NULL очень много чего можно сделать - как минимум почти всегда: для интерактивной программы - выдать сообщение о нехватки памяти с предложением освободить немного (в противном случае откат текущей операции для потоковой/скриптовой/консольной программы выдать сообщение о нехватке памяти на stderr и вернуть код ошибки, который может быть проанализирован, вместо тихого segfault-а.
прелестями динамического выделения можно воспользоваться и без маллока
прелестями динамического выделения можно воспользоваться и без маллокаВ языке C средствами стандартной библиотеки?
Конечно можно: с помощью calloc/realloc.
Интересно, как в C использовать динамическую памать без malloc/calloc/realloc?
asm?
через платформозависимые вызовы.
Ты это сказал исключительно ради красного словца или действительно так считаешь?
Я думаю, что у был риторический вопрос. А если кто-то начнет говорить, что он еще в детстве писал свой собственный malloc на asm-е, то я готов дать этому человеку shell-овый логин на BSD-е и пусть он повторит свой подвиг.
Я думаю, что у был риторический вопрос. А если кто-то начнет говорить, что он еще в детстве писал свой собственный malloc на asm-е, то я готов дать этому человеку shell-овый логин на BSD-е и пусть он повторит свой подвиг.
Ты явно переоцениваешь сложность этого "подвига"
через платформозависимые вызовы.угу
ключевое слово "платформозависимые"
прелестями динамического выделения можно воспользоваться и без маллокаУгу. IPC shared mem или mmap?
чювак, например в винде есть апи функции управления кучей, в никсах наверняка тоже что то есть.
Правильная программа не использует malloc.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
> Когда malloc возвращает NULL, обычно ничего исправить уже нельзя.
Наглая ложь.
Обычно можно переписать всё так, чтобы не использовать malloc и т. п.
---
...Я работаю антинаучным аферистом...
Наглая ложь.
Обычно можно переписать всё так, чтобы не использовать malloc и т. п.
---
...Я работаю антинаучным аферистом...
Наглая ложь.Можно подробнее про неиспользование malloc'a? Я надеюсь, что оно не заключается в замене шила на мыло, или на new, который по сути - тот же malloc? Откуда брать память?
Обычно можно переписать всё так, чтобы не использовать malloc и т. п.
Из стека, конечно !
Судя по дате регистрации, первый раз Контру видишь ?
Судя по дате регистрации, первый раз Контру видишь ?
Из стека.
Если не хватает одного, сделать ещё один.
---
"Just let me listen to my rock'n'roll music..."
Если не хватает одного, сделать ещё один.
---
"Just let me listen to my rock'n'roll music..."
Идею понял, но мне не кажется это правильным... Оставим за кадром вопрос "а хватит ли стека", и т.п. Выделение из стека подразумевает, что память, выделенная в какой-то функции, должна быть освобождена по завершению работы этой функции, правильно ли я понимаю? Это значит, что подобной конструкции, типичной для "объектного" подхода, использовать не получится:
///////////////
func_main(ing something)
{
init_object(obj); // Ининиализируем сложный объект, размер которого заранее не известен
if(something)
do_with_object_1(obj);
else
do_with_object_2(obj);
destroj_object(obj);
}
/////////////////
Я догадываюсь, что возможно это уже обсуждалось... Но мне не понятно, а искать в архивах - долго...
///////////////
func_main(ing something)
{
init_object(obj); // Ининиализируем сложный объект, размер которого заранее не известен
if(something)
do_with_object_1(obj);
else
do_with_object_2(obj);
destroj_object(obj);
}
/////////////////
Я догадываюсь, что возможно это уже обсуждалось... Но мне не понятно, а искать в архивах - долго...
Если тебе очень нужна куча, то работай с кучей.
Но не через malloc.
---
...Я работаю антинаучным аферистом...
Но не через malloc.
---
...Я работаю антинаучным аферистом...
> Если тебе очень нужна куча, то работай с кучей.
> Но не через malloc.
Я бы поспорил, нужен ли malloc или нет, и нужно ли писать собственную версию, но видимо действительно за свои 3 месяца регистрации я не всё видел
> Но не через malloc.
Я бы поспорил, нужен ли malloc или нет, и нужно ли писать собственную версию, но видимо действительно за свои 3 месяца регистрации я не всё видел
> Выделение из стека подразумевает, что память,
> выделенная в какой-то функции, должна быть освобождена
> по завершению работы этой функции, правильно ли я понимаю?
Нет.
> Это значит, что подобной конструкции, типичной для "объектного" подхода,
> использовать не получится:
Ну так и не используй.
---
...Я работаю антинаучным аферистом...
> выделенная в какой-то функции, должна быть освобождена
> по завершению работы этой функции, правильно ли я понимаю?
Нет.
> Это значит, что подобной конструкции, типичной для "объектного" подхода,
> использовать не получится:
Ну так и не используй.
---
...Я работаю антинаучным аферистом...
> Правильная программа не использует malloc.
Это низкоуровневная программа, а не правильная программа, обычно стараются не использовать работу с кучей(malloc).
ps
Если кол-во и время жизни разных сущностей в программе сильно зависит от внешнего окружения, то без кучу ты все равно не обойдешься (одних стеков тебе не хватит).
Это низкоуровневная программа, а не правильная программа, обычно стараются не использовать работу с кучей(malloc).
ps
Если кол-во и время жизни разных сущностей в программе сильно зависит от внешнего окружения, то без кучу ты все равно не обойдешься (одних стеков тебе не хватит).
одних стеков тебе не хватитНе, ну если стеки будут образовывать кучу...
должно хватитьРасскажи, как сделана куча.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
куча, в отличие от стека, позволяет удаление из середины.
Стек тоже позволяет удалять из середины.
---
"Расширь своё сознание!"
---
"Расширь своё сознание!"
> Стек тоже позволяет удалять из середины
тогда чем тогда такой хитрый стек отличается от кучи?
тогда чем тогда такой хитрый стек отличается от кучи?
>> Выделение из стека подразумевает, что память,
>> выделенная в какой-то функции, должна быть освобождена
>> по завершению работы этой функции, правильно ли я понимаю?
>Нет.
Хорошо, тогда я говорю про реализацию в C/C++, когда я создаю массив, место под который прозрачным образом выделяется в стеке. Если же мне нужно выделять память явно, то тогда как минимум, нужны серьёзные основания для того, чтобы утрерждать, что от использования malloc/new нужно отказываться.
>> Это значит, что подобной конструкции, типичной для "объектного" подхода,
>> использовать не получится:
> Ну так и не используй.
Почему? Ради чего отказываться от очень удобных и полезных конструкций?
> Стек тоже позволяет удалять из середины.
По определению - не позволяет, иначе это уже не стек будет.
Далее, рассмотрим случай, когда констукция позволяет удалять из середины. Тогда получается, что мы или должны сдвигать все последующие элементы на освободившиеся места, что занимает много времени и создаёт большие проблемы для указателей, или же мы изначально должны работать не с непрерывным учаском памяти, а с таблицей указателей, но тогда это будет просто одной из возможных реализаций полного аналога malloc'а....
Я опять что-то непонимаю?
>> выделенная в какой-то функции, должна быть освобождена
>> по завершению работы этой функции, правильно ли я понимаю?
>Нет.
Хорошо, тогда я говорю про реализацию в C/C++, когда я создаю массив, место под который прозрачным образом выделяется в стеке. Если же мне нужно выделять память явно, то тогда как минимум, нужны серьёзные основания для того, чтобы утрерждать, что от использования malloc/new нужно отказываться.
>> Это значит, что подобной конструкции, типичной для "объектного" подхода,
>> использовать не получится:
> Ну так и не используй.
Почему? Ради чего отказываться от очень удобных и полезных конструкций?
> Стек тоже позволяет удалять из середины.
По определению - не позволяет, иначе это уже не стек будет.
Далее, рассмотрим случай, когда констукция позволяет удалять из середины. Тогда получается, что мы или должны сдвигать все последующие элементы на освободившиеся места, что занимает много времени и создаёт большие проблемы для указателей, или же мы изначально должны работать не с непрерывным учаском памяти, а с таблицей указателей, но тогда это будет просто одной из возможных реализаций полного аналога malloc'а....
Я опять что-то непонимаю?
Надо использовать GC, вот и все.
Что?
Тем, что это стек, а потому он значительно проще кучи.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Для использования или для реализации?
И для того, и для другого.
---
"Это проявление Аль-Хагг..."
---
"Это проявление Аль-Хагг..."
Речь о стеке с удалением из середины за O(n) ?
Что обозначено через "n"?
---
...Я работаю...
---
...Я работаю...
Длина (глубина) стека
Если делать всё правильно, то можно быстрее.
---
"Расширь своё сознание!"
---
"Расширь своё сознание!"
>> Если делать всё правильно, то можно быстрее.
Ага, и тогда получится на самом деле куча, только с претензией на стекообразность =)
Ага, и тогда получится на самом деле куча, только с претензией на стекообразность =)
Если делать неправильно --- да.
Если же всё делать правильно, будет обычный стек.
---
"Расширь своё сознание!"
Если же всё делать правильно, будет обычный стек.
---
"Расширь своё сознание!"
Кстати, если умело действовать, то удаление из стека любой глубины будет O(1).
Как это сделать, оставляю в качестве домашнего задания.
---
...Я работаю антинаучным аферистом...
Как это сделать, оставляю в качестве домашнего задания.
---
...Я работаю антинаучным аферистом...
Что ты называешь "элементом" своего стека? Задача аллокации элементов фиксированного размера слишком тривиальна чтобы ее обсуждать, не находишь? И вообще что значит "удалить" в середине стека элемент? Сдается, ты мыслишь этот свой "стек" надстройкой над уже кем-то построенным хипом, какая тогда от него польза?
1. Объект произвольной известной длины.
2. Знаю об этом.
3. Осуществить преобразование: <1> ... <n> мусор <верхний> --> <1> ... <n> <верхний>
4.1. Нет.
4.2. Большая.
---
...Я работаю антинаучным аферистом...
2. Знаю об этом.
3. Осуществить преобразование: <1> ... <n> мусор <верхний> --> <1> ... <n> <верхний>
4.1. Нет.
4.2. Большая.
---
...Я работаю антинаучным аферистом...
Что ты называешь "элементом" своего стека? Задача аллокации элементов фиксированного размера слишком тривиальна чтобы ее обсуждать, не находишь?Не очевидно. Может расскажешь как реализовать аллокации большого числа элементов фиксированного размера так, чтобы выделение (освобождение) было максимально эффективным. Мне вот кажется не такой уж и тривиальной задачей.
Хотя может быть это я такой темный
Так я так понимаю вопрос был в том, как именно удалять, т.е. копировать или нет? Не могли бы Вы более подробно написать?
Достаточно понять, как в сях получается удаление из середины стека.
Это достаточно просто и часто встречается.
Просто это хорошо спрятано за блочной структурой.
---
"Расширь своё сознание!"
Это достаточно просто и часто встречается.
Просто это хорошо спрятано за блочной структурой.
---
"Расширь своё сознание!"
Достаточно понять, как в сях получается удаление из середины стека.Я всё же не понимаю...
Это достаточно просто и часто встречается.
Просто это хорошо спрятано за блочной структурой.
Во-первых, если мы работаем в C/C++, то из-за наличия указателей необходимо, чтобы физически выделенная память оставалась на прежнем месте, перекопирование не допускается.
Допустим, мы работаем с блоками одинакового размера. В этом случае, если я правильно понимаю, то, что ты описываешь, называется "двухсторонне связанный список", и мы работаем со структурами вида "id предыдущего, id следующего, номер блока". Соответственно, есть две структуры, структура свободных и структура занятых блоков. В таком варианте конструкция работает очень хорошо, можно сказать - идеально. Но - это не стек по определению, это двухсторонне связанный (или двунаправленный - не помню точно, как это корректно называется) список. Далее, рассмотрим ситуацию, когда мы работаем с блоками переменной длины. В этом случае, так как в C/C++ необходима поддержка указателей, то есть конструкций вида *(ptr+NNN)=XXX;, и из-за этого адресное пространство выделяемого блока должно быть монолитным. Это значит, что выделяемый блок необходимо составить из нескольких малых блоков, а значит или память нужно двигать, или может случиться так, что выделенный блок будет немонолитным. Обе ситуации не приемлимы. В любом случае, получается свой менеджер памяти.
Походу в алгоритмах ты нихрена не шаришь. Прислушайся к тому, что тебе люди говорят ну или объясни подробнее, свою мысль.
Использовать указатели --- это требование религии?
Нет, я не говорю ни про какие связанные списки.
Память так или иначе приходится двигать,
и это не обойти, пока ты используешь столь низкоуровневые языки,
вроде сей или приплюснутых сей.
Если ты заведёшь ещё один стек, то и соответствующие средства
работы с ним образуют "свой менеджер памяти",
пусть он и заключается в действии смещения указателя вершины стека.
---
"Расширь своё сознание!"
Нет, я не говорю ни про какие связанные списки.
Память так или иначе приходится двигать,
и это не обойти, пока ты используешь столь низкоуровневые языки,
вроде сей или приплюснутых сей.
Если ты заведёшь ещё один стек, то и соответствующие средства
работы с ним образуют "свой менеджер памяти",
пусть он и заключается в действии смещения указателя вершины стека.
---
"Расширь своё сознание!"
Походу в структурах данных ты нихрена не шаришь.
Включи мозг и подумай.
---
"Расширь своё сознание!"
Включи мозг и подумай.
---
"Расширь своё сознание!"
Видимо не шарю, вот и хочется открыть что-то новое для себя в этой области. Хоть ссылку дай почитать
Керниган объясняет, как сделан стек в сях?
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Я тебе не говорю про конкретную реализацию - смотри шире. И сообрази, что эффективную структуру данных работы с памятью на основе стека сделать нельзя. Либо, это нужно называть своими именами, а не стеком Обрати внимание, что тебе уже дал подробный ответ.
Чтобы конкретнее разговаривать. Приведи список операций, которые умеет делать твой уникальный стек и для каждой операции прикинь асимптотику ее выполнения. А мы тебе раскажем что это за такая реализация и как она называется
Обрати внимание, что тебе уже дал подробный ответ.Чтобы конкретнее разговаривать. Приведи список операций, которые умеет делать твой уникальный стек и для каждой операции прикинь асимптотику ее выполнения. А мы тебе раскажем что это за такая реализация и как она называется
Просмотрел еще раз Кернигана и что-то не нашел, чтобы там шло описания работы с динамической памятью путем отказа от malloc через стек. В книжке вроде бы подробно разъясняется как происходят вызовы функций, как функционирует сам стек. Но заметь, что про работу с блоками памяти нет ни слова. Что-то я не нашел, где там дается описание как удалять из середины стека. Или я в чем-то не прав?
bcopy одного элемента зависит от глубины стека?
Сложение зависит?
return/longjmp зависит?
Вот и получается, что удаление из стека производится за O(1 а не O(n).
---
...Я работаю антинаучным аферистом...
Сложение зависит?
return/longjmp зависит?
Вот и получается, что удаление из стека производится за O(1 а не O(n).
---
...Я работаю антинаучным аферистом...
bcopy одного элемента зависит от глубины стека?Не зависит, только копировать приходится не один элемент.
По ходу дела ты рассматриваешь только операции Push и Pop, которые очевидно работают за O(1 а операций удаления из середины стека у тебе просто не предусмотрено (хотя двунаправленный список спасает ситуацию). Но вот удалять и выделять блоки произвольного размера уже не получится точно!
Попробуй объясни, как последовательный вызов комманд malloc и freeс разной величиной блоков реализовать при помощи стека?
В том-то и дело, что один.
free для верхних элементов знаешь, как сделать.
А free для нижних элементов откладывается на потом.
Лечись от обобщизма.
---
"Математик может говорить, что ему хочется,
но физик должен, хотя бы в какой-то мере, быть в здравом рассудке."
Дж. В. Гиббс
free для верхних элементов знаешь, как сделать.
А free для нижних элементов откладывается на потом.
Лечись от обобщизма.
---
"Математик может говорить, что ему хочется,
но физик должен, хотя бы в какой-то мере, быть в здравом рассудке."
Дж. В. Гиббс
Если я тебя правильно понял, то это влечёт очень нерациональный расход памяти...
В зависимости от.
Разумеется, если ты очень хочешь очень экономить память,
можешь пожертвовать скоростью и устроить кучу.
Или сделать удаление за O(n).
---
...Я работаю...
Разумеется, если ты очень хочешь очень экономить память,
можешь пожертвовать скоростью и устроить кучу.
Или сделать удаление за O(n).
---
...Я работаю...
Реально круто! Ты сделал клевое открытие Срочно ботаю ASM и изучаю исходники
Кстати, если почитаешь Кернигана повнимательнее, там написано для каких ситуаций описанная тобой стратегия работает неплохо - постоянно что-то небольших размеров переменной длины выделяется и освобождается.
Если бы все было настолько просто, люди бы не стратади и не думали как сделать виртуальную память, какие алгоритмы использовать, операции malloc и free бы тогда не тормозили. Была бы польная идилия. Но учитывая, что все эти аспекты в настоящее время присутсвуют, эффективной структуры для выделяения и освобождения памяти не придуманы. Всегда приходится чем-то жертвовать либо скоростью, либо объемами нерационально выделенной памяти.
Ладно, думаю тут предельно понятно, что ты имеешь в виду, и все вытекающие отсюда проблемы. Можно завтра дисскусию продолжить, если тебе еще что-то не ясно
Срочно ботаю ASM и изучаю исходники Кстати, если почитаешь Кернигана повнимательнее, там написано для каких ситуаций описанная тобой стратегия работает неплохо - постоянно что-то небольших размеров переменной длины выделяется и освобождается.
Если бы все было настолько просто, люди бы не стратади и не думали как сделать виртуальную память, какие алгоритмы использовать, операции malloc и free бы тогда не тормозили. Была бы польная идилия. Но учитывая, что все эти аспекты в настоящее время присутсвуют, эффективной структуры для выделяения и освобождения памяти не придуманы. Всегда приходится чем-то жертвовать либо скоростью, либо объемами нерационально выделенной памяти.
Ладно, думаю тут предельно понятно, что ты имеешь в виду, и все вытекающие отсюда проблемы. Можно завтра дисскусию продолжить, если тебе еще что-то не ясно
Где тут "очень экономить"?
Если, например, хотим постоянно хранить два или три числа - предыдущее, текущее, следующее - если делать это с помощью твоего "стека" - кончится любое количество памяти.
Если, например, хотим постоянно хранить два или три числа - предыдущее, текущее, следующее - если делать это с помощью твоего "стека" - кончится любое количество памяти.
Милый ,
тот факт, что что malloc возвращает NULL не является минусом реализации malloc-а, он просто означает, что твоя программа не может получить больше памяти. Почему, это отдельный вопрос. Может админ запретил выделять больше, может параллельно запущенная прога сожрала всю память, а может кто-то просто вытащил планку памяти, в общем не суть. В такой ситуации все твои предложения отказаться от malloc-а и перейти на стек посылаются куда подальше - ты хоть на два стека перейди, но это не изменит решение администратора о том, сколько памяти нужно твоей программе, и, как бы это не было обидно, не вставит еще одну планку памяти.
тот факт, что что malloc возвращает NULL не является минусом реализации malloc-а, он просто означает, что твоя программа не может получить больше памяти. Почему, это отдельный вопрос. Может админ запретил выделять больше, может параллельно запущенная прога сожрала всю память, а может кто-то просто вытащил планку памяти, в общем не суть. В такой ситуации все твои предложения отказаться от malloc-а и перейти на стек посылаются куда подальше - ты хоть на два стека перейди, но это не изменит решение администратора о том, сколько памяти нужно твоей программе, и, как бы это не было обидно, не вставит еще одну планку памяти.
При работе с динамическими структурами чаще всего встречается две задачи: выделить память под N-байт и выделить память под некую структуру. Для решения первой задачи malloc подходит идеально, а при помощи функции sizeof подходит и для решения второго типа задач.
Можешь описать, как ты собираешся реализовывать подобные задачи на стеке или что тебе там большее нравится?
Можешь описать, как ты собираешся реализовывать подобные задачи на стеке или что тебе там большее нравится?
А free для нижних элементов откладывается на потом.Может так оказаться, что никакого "потом" не будет. Ну зачем я что-то пишу в ответ КОНТРЕ ?
> А free для нижних элементов откладывается на потом.
это, наверное, все правильно - только речь сейчас идет не об абстрактной машине Тьюринга, а о конкретных программах на конкретных исполнителях, которые, как я уже писал, часто вынуждены работать с сущностями время жизни которых различно и сильно зависит от окружения в момент запуска.
это, наверное, все правильно - только речь сейчас идет не об абстрактной машине Тьюринга, а о конкретных программах на конкретных исполнителях, которые, как я уже писал, часто вынуждены работать с сущностями время жизни которых различно и сильно зависит от окружения в момент запуска.
сейчас идет не об абстрактной машине Тьюринга, а о конкретных программах на конкретных исполнителях, которые, как я уже писал, часто вынуждены работать с сущностями время жизни которых различно и сильно зависит от окружения в момент запуска.ура!
надо полагать, теперь ты наконец-то покажешь примеры правильных в программ!
В том-то и дело, что один.Плохая идея. Сравнима с тем, чтобы память вообще не освобождать.
free для верхних элементов знаешь, как сделать.
А free для нижних элементов откладывается на потом.
Лечись от обобщизма.
Например, программа в самом начале считывает из файла матрицу, чтобы найти решение соответствующего ЛУ, выделяет много памяти под промежуточные матрицы, в итоге получает вектор со значениями. Вполне нормально будет, что промежуточные матрицы будут сначала находиться в памяти, а итоговой вектор (который и нужен дальше в программе) - за ними. Вот получается, что довольно большой объём памяти не может быть освобождён только из-за того, что не удалён относительно небольшой кусок памяти под итоговый вектор.
Короче, я не очень понимаю - тебе не нравится внутренняя организация malloc (тогда чем, и чем то, что ты предлагаешь, принципиально отличается? либо тебе не нравится архитектура malloc-free (или new-delete)?
> надо полагать, теперь ты наконец-то покажешь примеры правильных в этом смысле программ!
ты до сих пор не видел примеры такого подхода?
Страуструпа хотя бы открывал? Базовые идеи такого подхода у него описываются.
ты до сих пор не видел примеры такого подхода?
Страуструпа хотя бы открывал? Базовые идеи такого подхода у него описываются.
>> надо полагать, теперь ты наконец-то покажешь примеры правильных в этом смысле программ!
> ты до сих пор не видел примеры такого подхода?
меня не примеры подхода с базовыми идеями интересуют, а реальные программы
причём, чтобы там был чистый malloc с проверками на ошибки
> ты до сих пор не видел примеры такого подхода?
меня не примеры подхода с базовыми идеями интересуют, а реальные программы
причём, чтобы там был чистый malloc с проверками на ошибки
> причём, чтобы там был чистый malloc с проверками на ошибки
такого точно не бывает, потому что это дорого.
такого точно не бывает, потому что это дорого.
дорого, да, но, всё-таки, хотелось увидеть чудо
> меня не примеры подхода с базовыми идеями интересуют, а реальные программы
> причём, чтобы там был чистый malloc с проверками на ошибки
Может быть не совсем конктерный пример, потому как без исходников, и не знаю, на чём написана программа. ACDSEE (просмотрщик картинок под Win32)
Программа пытается открыть файл с изображением, однако разрешение его слишком большое, и оперативной памяти для этого не хватит. Тогда программа отлавливает, что памяти не хватает, и эту конкретную картинку отказывается просматривать в родном разрешении (в меньших - можно не вылетая при этом. Вот правильная обработка нехватки памяти - ту часть работы, на которую памяти не хватает, программа не делает, но остальные задания корректно обрабатывает.
> причём, чтобы там был чистый malloc с проверками на ошибки
Может быть не совсем конктерный пример, потому как без исходников, и не знаю, на чём написана программа. ACDSEE (просмотрщик картинок под Win32)
Программа пытается открыть файл с изображением, однако разрешение его слишком большое, и оперативной памяти для этого не хватит. Тогда программа отлавливает, что памяти не хватает, и эту конкретную картинку отказывается просматривать в родном разрешении (в меньших - можно не вылетая при этом. Вот правильная обработка нехватки памяти - ту часть работы, на которую памяти не хватает, программа не делает, но остальные задания корректно обрабатывает.
К сожалению, это не совсем то.
Настоящие проблемы возникают, когда памяти перестаёт хватать для простейших операций, например элемент в какой-нибудь внутренний список добавить или ещё что-нибудь запомнить. Хуже всего, когда глюки от нехватки возникают не в самой программе, а в каком-нибудь из используемых ей посторонних API. Тут, вроде, и хочется всё сделать правильно, а не удастся.
Использование исключений и кучи с GC проблему в большинстве случаев решит, нужно только обработчики не забывать, а с чистым malloc будет очень тяжело.
Настоящие проблемы возникают, когда памяти перестаёт хватать для простейших операций, например элемент в какой-нибудь внутренний список добавить или ещё что-нибудь запомнить. Хуже всего, когда глюки от нехватки возникают не в самой программе, а в каком-нибудь из используемых ей посторонних API. Тут, вроде, и хочется всё сделать правильно, а не удастся.
Использование исключений и кучи с GC проблему в большинстве случаев решит, нужно только обработчики не забывать, а с чистым malloc будет очень тяжело.
> теперь ты наконец-то покажешь примеры правильных в этом смысле программ!
linux kernel (да и наверное любое ядро) не устраивает?
linux kernel (да и наверное любое ядро) не устраивает?
Не особо, так как очень плохо обобщается на прикладные программы. Библиотеки написаны гораздо более паршиво, чем внутренности у ядер ОС, поэтому многое придётся реализовывать с нуля, а это дорого.
А ты выдели память под итоговый вектор заранее.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Разве что один раз проделать весь этот гемор, создав виртуальную машину для каких-нибудь Java, Lisp, Haskell или ещё чего-нибудь.
А зачем? Какие плюсы даёт отказ от использования malloc/new, чтобы из-за этого нужно при программировании заботиться о том, в какой последовательности нужно выделять память под объекты? Минусы, в виде дополнительной работы и отвлечения внимания я вижу... Плюсов - не вижу. Поэтому вопрос мой сводится к "ради чего вообще отказываться от malloc/new, какие плюсы это даст"?
Чё за GC?
> ради чего вообще отказываться от malloc/new, какие плюсы это даст
Ради того, чтобы вообще не следить за порядком выделения и освобождения памяти.
---
"Расширь своё сознание!"
Ради того, чтобы вообще не следить за порядком выделения и освобождения памяти.
---
"Расширь своё сознание!"
RTFM: garbage collection
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Как же не следить, если наоборот нужно следить, в какрм порядке выделять?
А ты выдели память под итоговый вектор заранее.
> ради чего вообще отказываться от malloc/new, какие плюсы это дастЛадно, всё понятно... Короче, так и нужно было говорить, что агитируешь за сборку мусора и за "правильные языки"... А то стек, стек...
Ради того, чтобы вообще не следить за порядком выделения и освобождения памяти.
За оптимизацией должен, вообще говоря, следить компилятор.
Человек должен думать.
---
"Так завещал великий и мудрый Ибеме..."
Человек должен думать.
---
"Так завещал великий и мудрый Ибеме..."
> Библиотеки написаны гораздо более паршиво, чем внутренности у ядер ОС
У ядра вместо таких библиотек - user-level процессы, выполняющиеся в отдельном адресном пространстве, в случае чего процесс прибивается целиком, и некоторые виды мусора за ним подчищаются.
У ядра вместо таких библиотек - user-level процессы, выполняющиеся в отдельном адресном пространстве, в случае чего процесс прибивается целиком, и некоторые виды мусора за ним подчищаются.
Ну да, виртуальная машина.
Многие либы просто так не прибить, если они сходят с ума в том же адресном пространстве.
Многие либы просто так не прибить, если они сходят с ума в том же адресном пространстве.
ACDSEE пытается выделить память, но ее не хватает, тогда она пытается показать окошко с сообщением об ошибке, но памяти под окно уже тоже нет, да и идентификаторы окон давно закончились, а юзверь продолжает ждать уже вторую сотню лет ответа от программы, ведь ему сказали, что она всегда работает без ошибок.
По-моему заботиться о нехватке памяти нужно лишь в случаях когда выделяются блоки более 200Mb-500Mb - просто нужно запрещать операции при выполнении которых будет превышен этот предел (если это заранее (или во время работы на небольшом участке) определить можно даже если память еще есть. А в пределах 200-500Mb память всегда найдется - а если вы выключили swap, то это ваши проблемы.
По-моему заботиться о нехватке памяти нужно лишь в случаях когда выделяются блоки более 200Mb-500Mb - просто нужно запрещать операции при выполнении которых будет превышен этот предел (если это заранее (или во время работы на небольшом участке) определить можно даже если память еще есть. А в пределах 200-500Mb память всегда найдется - а если вы выключили swap, то это ваши проблемы.
А это уже зависит от степени параноидальности программиста.
Хотя даже в этом случае, одно дело, когда программа вывались в кору из-за обращения к указателю NULL, и совсем другое дело, когда в логах системы появилась запись о нехватке идентификаторов окон.
Хотя даже в этом случае, одно дело, когда программа вывались в кору из-за обращения к указателю NULL, и совсем другое дело, когда в логах системы появилась запись о нехватке идентификаторов окон.
По-моему заботиться о нехватке памяти нужно лишь в случаях когда выделяются блоки более 200Mb-500Mb - просто нужно запрещать операции при выполнении которых будет превышен этот предел (если это заранее (или во время работы на небольшом участке) определить можно даже если память еще есть. А в пределах 200-500Mb память всегда найдется - а если вы выключили swap, то это ваши проблемы.И еще скажи, что у тебя все файлы на жестком диске меньше 200-500Mb. К примеру, крупные БД и расчетные программы выделяют и работают с объемами памяти более 200-500Mb. Просто им без этого нельзя.
> тогда она пытается показать окошко с сообщением об ошибке, но памяти под окно уже тоже нет, да и идентификаторы окон давно закончились
Здесь соглашусь с Контрой, что память и другие ресурсы под аварийную систему должны выделяться заранее, например, сразу при старте программы - тогда и не будет таких проблем.
Здесь соглашусь с Контрой, что память и другие ресурсы под аварийную систему должны выделяться заранее, например, сразу при старте программы - тогда и не будет таких проблем.
Например так: brk mmap/mumap.
Я в своё время писал штук пять разных malloc'а. Самый простой занимал с десяток строк, самый сложный использовал сбалансированное дерево, самый низкоуровневый проверял, сколько памяти в машине (запускался без ОС в нулевом кольце защиты) и выделял её постранично.
Ни один не содержал ни одной ассемблерной строки, работы с портами или биосом.
Ни один не содержал ни одной ассемблерной строки, работы с портами или биосом.
Есть и стандартные POSIX-вызовы: mmap, например.через платформозависимые вызовы.угу
ключевое слово "платформозависимые"
конечноЕсть и стандартные POSIX-вызовы: mmap, например.через платформозависимые вызовы.угу
ключевое слово "платформозависимые"
Вот только стандартные POSIX-вызовы тоже платформозависимые в том смысле, который я подразумевал, хотя и портируемы между POSIX-совместимыми окружениями. Очевидно POSIX-вызовы доступны только в системе, поддерживающей POSIX API, а не являются возможностями языка программирования C, как функции стандартной библиотеки.
Хотя это и прозвучит как ересь, но стандартные POSIX-вызовы ни чем не лучше, чем например вызовы Win32 API, несмотря на стандартизированность и реализованность на большем количестве платформ. Просто POSIX - это стандарт не имеющий прямого отношения к языку C, хотя и ссылающийся на стандарт C.
> а не являются возможностями языка программирования C,
> как функции стандартной библиотеки.
Последние тоже не являются возможностями языка программирования С,
а существуют независимо.
Мало того, это прозвучит как ересь, но очень много функций стандартной библиотеки платформозависимы.
В частности, довольно сильно опираются на тот же POSIX.
POSIX, кстати, имеет прямое отношение к языку C.
---
...Я работаю антинаучным аферистом...
> как функции стандартной библиотеки.
Последние тоже не являются возможностями языка программирования С,
а существуют независимо.
Мало того, это прозвучит как ересь, но очень много функций стандартной библиотеки платформозависимы.
В частности, довольно сильно опираются на тот же POSIX.
POSIX, кстати, имеет прямое отношение к языку C.
---
...Я работаю антинаучным аферистом...
Последние тоже не являются возможностями языка программирования С,Что значит "независимо"? Как что реализовано никого не волнует.
а существуют независимо.
Главное, что стандартная библиотека описана в стандарте языка C, а значит является его частью по определению, ибо по определению стандарт языка C определяет язык C.
Впрочем формальный взгляд на этот вопрос не важен: если привык, можно логически отделять язык от стандартной библиотеки, но самое главное, что стандартная библиотека описана в стандарте C (в отличие от POSIX API а значит она необходима для реализации на любой платформе совместимой со стандартом (с поддержкой host environment) - т.е. поддерживающей язык C, а вот POSIX - нет. Даже для совместимости с C standalone environment функциональность некоторых header-ов необходима (типа <stddef.h>, <stdint.h>, <float.h>, <limits.h>).
Мало того, это прозвучит как ересь, но очень много функций стандартной библиотеки платформозависимы.видимо потому, что это и есть ересь.
В частности, довольно сильно опираются на тот же POSIX.
Что это вообще значит? Что такое "платформозависимы" в твоей терминологии? Реализации функций стандартной библиотеки под винду тоже сильно опираются на POSIX?
Функциональность стандартной библиотеки описана в стандарте языка программирования и она одинакова вне зависимости от платформы поддерживающей C host environment, в том числе независимо от того реализован ли POSIX API в данной ОС.
Одинаковая функциональность API на любой платформе, четко описанная в его спецификации, - это и есть по определению платформонезависимость API.
Очевидно POSIX тоже является платформонезависимым API для систем поддерживающих POSIX, но не для систем в которых можно программировать на языке C, и так же не для систем, на которых поддерживается C host environment.
Функции стандартной библиотеки опираются на стандарт C, а не на POSIX разумеется. Они конечно могут быть реализованы, посредством вызова POSIX функций (которые обычно являются прямыми системными вызовами а могут быть реализованы вызовами Win32 API или вообще непосредственным доступом к оборудованию. Важна их [функций стандартной библиотеки] стандартная функциональность и ее платформонезависимость, а не то, как они реализованы.
POSIX, кстати, имеет прямое отношение к языку C.POSIX опирается на стандарт C, а вот C не опирается на POSIX.
> Что значит "независимо"?
> Как что реализовано никого не волнует.
То и значит, что независимо.
Если по-твоему библиотеки являются частью языка,
то это получается очень уж убогий язык.
То, что никого не волнует, как это реализовано, является откровенной ложью.
> Даже для совместимости с C standalone environment
> функциональность некоторых header-ов необходима
> (типа <stddef.h>, <stdint.h>, <float.h>, <limits.h>).
Это вообще является наглой ложью.
> POSIX опирается на стандарт C,
> а вот C не опирается на POSIX.
Это вообще противоречит твоему первому заявлению,
что библиотека входит в язык.
---
"Narrowness of experience leads to narrowness of imagination."
> Как что реализовано никого не волнует.
То и значит, что независимо.
Если по-твоему библиотеки являются частью языка,
то это получается очень уж убогий язык.
То, что никого не волнует, как это реализовано, является откровенной ложью.
> Даже для совместимости с C standalone environment
> функциональность некоторых header-ов необходима
> (типа <stddef.h>, <stdint.h>, <float.h>, <limits.h>).
Это вообще является наглой ложью.
> POSIX опирается на стандарт C,
> а вот C не опирается на POSIX.
Это вообще противоречит твоему первому заявлению,
что библиотека входит в язык.
---
"Narrowness of experience leads to narrowness of imagination."
То и значит, что независимо.Что "то"?
"Вероятность пересечения равна произведению вероятностей"?
Что это значит в данном контексте? Что разные packages реализуют freesanding implementation и большую часть стандартной библиотеки? Какое это вообще имеет отношение к делу? Ты вообще стандарт C читал когда-нибудь? Слышал о его существовании хотя бы?
То, что никого не волнует, как это реализовано, является откровенной ложью.Хорошо согласен, тогда перефразирую так:
Если человека, пишущего программу, использующую стандартную библиотеку, волнует то, как реализована стандартная библиотека, а не то, что она делает, то этот человек некомпетентен. Ибо если пишется C прога (или часть проги использующая только стандартную библиотеку, эта прога (или часть проги) должна работать одинаково везде, где есть реализация C hosted implementation, совместимая со стандартом.
Вполне правомерно волнует реализация стандартной библиотеки в следующих случаях: (1) при выборе той или иной реализации стандартной библиотеки на стадии использования (а не на стадии программирования (2) при написании собственной реализации стандартной библиотеки.
Если по-твоему библиотеки являются частью языка,Не библиотеки, а стандартная библиотека
то это получается очень уж убогий язык.
Что значит "убогий"? Более "убогий" чем без стандартной библиотеки?
Задолбал разговаривать лозунгами. Не пробовал строить информативные фразы? Бывает очень продуктивно.
> Даже для совместимости с C standalone environmentСтандарт почитай, епт.
> функциональность некоторых header-ов необходима
> (типа <stddef.h>, <stdint.h>, <float.h>, <limits.h>).
Это вообще является наглой ложью.
Прежде чем п*здеть. Подсказываю: параграф 4 - Conformance.Только правильный термин не "C standalone environment", а "C freestanding implementation". Впрочем по смыслу одно и то же.
И цитату приводи из стандарта языка C, которая обосновывает, что это ложь. Потому, что термины C hosted implementation и C freestanding implementation - это термины из стандарта C, и условие совместимости с оными определено этим стандартом.
> POSIX опирается на стандарт C,Что мой пост забыл прочесть прежде чем отвечать на него?
> а вот C не опирается на POSIX.
Это вообще противоречит твоему первому заявлению,
что библиотека входит в язык.
У меня не было заявления, что "библиотека входит в язык", у меня было заявление, что стандартная библиотека языка C, которая описывается в стандарте языка C, является частью языка C. Стандартная библиотека понимаешь? Уж конечно не POSIX, и не Win32 API, и не OpenGL, и т.д.
"Narrowness of experience leads to narrowness of imagination."exactly
>> Реализации функций стандартной библиотеки под винду тоже сильно опираются на POSIX?
Винда позикс-совместима, кстати.
Винда позикс-совместима, кстати.
>>Если человека, пишущего программу, использующую стандартную библиотеку, волнует то, как реализована стандартная библиотека, а не то, что она делает, то этот человек некомпетентен.
Наглая ложь(с)
Видишь ли, если человек пишет именно на С, а не на жаве или на шарпе, например, значит, его волнует в первую очередь скорость. Если бы его волновала кроссплатформенность, он наверняка бы не стал писать на языке, в котором не определён размер инта.
А когда человека волнует скорость, он, естественно, интересуется реализацией некоторых функций.
Наглая ложь(с)
Видишь ли, если человек пишет именно на С, а не на жаве или на шарпе, например, значит, его волнует в первую очередь скорость. Если бы его волновала кроссплатформенность, он наверняка бы не стал писать на языке, в котором не определён размер инта.
А когда человека волнует скорость, он, естественно, интересуется реализацией некоторых функций.
> Винда позикс-совместима, кстати.
Самой первой версии POSIX? Толку от этой совместимости ноль, разве что размахивать ей как флагом.
Самой первой версии POSIX? Толку от этой совместимости ноль, разве что размахивать ей как флагом.
// Задолбал разговаривать лозунгами.
Ничего другого ты и не получишь. Тебя же вроде предупреждали - смотри, с кем разговариваешь. Есть мнение, что этот твой собеседник - форумский робот.
Ничего другого ты и не получишь. Тебя же вроде предупреждали - смотри, с кем разговариваешь. Есть мнение, что этот твой собеседник - форумский робот.
Не очень понял, что ты хотел сказать. http://en.wikipedia.org/wiki/POSIX
он наверняка бы не стал писать на языке, в котором не определён размер инта.sizeof(int). Или тебе очень хочется знать, сколько именно бит он занимает?
Мне кажется, что это уже не забота программиста, а больше забота компилятора - высчитывать сколько именно занимает int. Если же тебе это сильно критично, то можно ввести свой тип (что-нить типа size_t) и в зависимости от конкретной платформы define-ить его на то, что тебе надо.
> Не библиотеки, а стандартная библиотека
Для тебя --- _стандартная_библиотека_.
> Что значит "убогий"?
> Более "убогий" чем без стандартной библиотеки?
То и значит --- убогий.
Посмотрел я, зачем нужен stddef.h.
О сях я был слишком хорошего мнения.
Оказывается, это ещё более убогий язык, чем я думал.
> Только правильный термин не "C standalone environment",
> а "C freestanding implementation".
> Впрочем по смыслу одно и то же.
То есть, ты отсылаешь к стандарту, которым сам не владеешь.
"C hosted implementation" и "C freestanding implementation"
никак не могут быть терминами из стандарта, потому что
термины стандарта вне стандарта вводятся через слово "standard".
Иначе это термины общего значения, и означают они ---
hosted & freestanding implementations resp.
> У меня не было заявления, что "библиотека входит в язык",
> у меня было заявление, что стандартная библиотека языка C,
> которая описывается в стандарте языка C,
> является частью языка C.
То есть часть целого не входит в целое.
Ты думай, что пишешь-то!
> Стандартная библиотека понимаешь?
Стандартн_ую_ библиотек_у_ не понимаю.
Успокойся прежде, чем писать.
Для тебя --- _стандартная_библиотека_.
> Что значит "убогий"?
> Более "убогий" чем без стандартной библиотеки?
То и значит --- убогий.
Посмотрел я, зачем нужен stddef.h.
О сях я был слишком хорошего мнения.
Оказывается, это ещё более убогий язык, чем я думал.
> Только правильный термин не "C standalone environment",
> а "C freestanding implementation".
> Впрочем по смыслу одно и то же.
То есть, ты отсылаешь к стандарту, которым сам не владеешь.
"C hosted implementation" и "C freestanding implementation"
никак не могут быть терминами из стандарта, потому что
термины стандарта вне стандарта вводятся через слово "standard".
Иначе это термины общего значения, и означают они ---
hosted & freestanding implementations resp.
> У меня не было заявления, что "библиотека входит в язык",
> у меня было заявление, что стандартная библиотека языка C,
> которая описывается в стандарте языка C,
> является частью языка C.
То есть часть целого не входит в целое.
Ты думай, что пишешь-то!
> Стандартная библиотека понимаешь?
Стандартн_ую_ библиотек_у_ не понимаю.
Успокойся прежде, чем писать.
Мне
надоели ноты ---
много больно пишут что-то.
> Или тебе очень хочется знать, сколько именно бит он занимает?
Кстати, как это сделать это в ходе сборки?
---
A44: Ламеры в гамаке пусть в тапках трахаются --- это их проблемы.
Я в своём гамаке хочу полноценно трахаться на лыжах.
Кстати, как это сделать это в ходе сборки?
---
A44: Ламеры в гамаке пусть в тапках трахаются --- это их проблемы.
Я в своём гамаке хочу полноценно трахаться на лыжах.
КОНТРА, всё забываю у себя спросить - а что ты используешь, кроме форта?
Схему.
---
"Пусть расцветают сто цветов, пусть борются сотни школ в идеологии."
---
"Пусть расцветают сто цветов, пусть борются сотни школ в идеологии."
Блок-схемы, в смысле?
> Блок-схемы, в смысле?
Не стебись, use rambler.
Функциональщик он, для него все остальные типы программирования не достойны Хорошо еще, что хоть не Луговский.
Не стебись, use rambler.
Функциональщик он, для него все остальные типы программирования не достойны
Хорошо еще, что хоть не Луговский.А ты на наш биореактор не наезжай!
---
"Химическая технология --- самая научная наука."
---
"Химическая технология --- самая научная наука."
Я не стебался...
Функциональщик он, для него все остальные типы программирования не достойныВпервые слышу такие умные слова... насколько я сейчас понял - он не кодер?
Мехматянин...
Значит, гуманитарий.
---
"Математика --- это язык."
Дж. В. Гиббс
---
"Математика --- это язык."
Дж. В. Гиббс
вопрос не в том, гуманитарий или нет... Просто все эти схемы и лиспы - это интересно, конечно, и местами очень полезно, однако не нужно пытаться навязать этот подход на все IT. Очень много областей, где такой подход, в общем, не приемлим, и то, что ты говорил про организацию памяти - тоже... И это серьёзные и нужные задачи, в которые нужно всерьёз погружаться - не нужно всё сводить к каким-то матмоделям.
Видишь ли, если человек пишет именно на С, а не на жаве или на шарпе, например, значит, его волнует в первую очередь скорость. Если бы его волновала кроссплатформенность, он наверняка бы не стал писать на языке, в котором не определён размер инта.не
если человека интересует только скорость - он пишет на ассемблере
а вот если человека интересует скорость и кроссплатформенность одновременно, тогда он пишет на C.
Размер инта и остальных типов очень даже определен и легко выясняется функциональностью <limits.h> и/или sizeof. Только он может быть различный для разных платформ. Некоторые трудности при обеспечении портируемости бинарных структур определенно есть, но они преодолимы, хотя и не с абсолютной портируемостью, но с очень большой степенью оной.А когда человека волнует скорость, он, естественно, интересуется реализацией некоторых функций.Когда речь идет о довольно элементарных и повсеместно используемых функциях, таких как функции стандартной библиотеки, вполне логично предположить, что наиболее распространенные реализации близки к максимальной эффективности (что и имеет место на практике а значит вполне достаточно иметь представление о производительности наилучших возможных реализаций стандартных функций, чтобы эффективно программировать для стандартной библиотеки.
А интересоваться как оно на самом деле где-то реализовано, разве что из любопытства или для общего развития, но уж никак не для оптимизации.
> Очень много областей, где такой подход, в общем, не приемлим
...Например.
Опять "narrowness of experience leads to narrowness of imagination?"
Значит, это наглая ложь.
> серьёзные и нужные задачи, в которые нужно всерьёз
> погружаться - не нужно всё сводить к каким-то матмоделям.
Серьёзные задачи требуют серьёзной мат. модели.
Это тебе не окошки рисовать.
---
"Люди недалёкие обычно осуждают всё,
что выходит за пределы их понимания."
...Например.
Опять "narrowness of experience leads to narrowness of imagination?"
Значит, это наглая ложь.
> серьёзные и нужные задачи, в которые нужно всерьёз
> погружаться - не нужно всё сводить к каким-то матмоделям.
Серьёзные задачи требуют серьёзной мат. модели.
Это тебе не окошки рисовать.
---
"Люди недалёкие обычно осуждают всё,
что выходит за пределы их понимания."
Серьёзные задачи требуют серьёзной мат. моделиМатмодели самой задачи, а не теории программирования
>> Реализации функций стандартной библиотеки под винду тоже сильно опираются на POSIX?Ну и что?
Винда позикс-совместима, кстати.
Все равно реализации стандартной библиотеки под винду обычно не через POSIX функции.
> Не библиотеки, а стандартная библиотекаА ведь в самом деле похоже на робота.
Для тебя --- _стандартная_библиотека_.
> Что значит "убогий"?
> Более "убогий" чем без стандартной библиотеки?
То и значит --- убогий.
А такие осмысленные некоторые реплики. Неужели AI боты уже достигли подобных высот? Да нееее... слишком осмысленно все же для робота, имхо.
> Опять "narrowness of experience leads to narrowness of imagination?"
А по русски? "создавать себе трудности на пустом месте только для ради того, чтобы их потом преодолевать"?
Это я к тому, что одно дело решать задачу, которую легко формализовать, но сложно решить, а другое дело - это "моделировать реальность". Возвращаясь к тому, о чём был тред - если есть объект, под который, например, выделяется память, то не всегда вообще возможно пресказать (даже на момент запуска программы сколько этот объект будет жить, сколько ресурсов потреблять, и соответственно, где его рациональнее расположить в памяти...
А по русски? "создавать себе трудности на пустом месте только для ради того, чтобы их потом преодолевать"?
Это я к тому, что одно дело решать задачу, которую легко формализовать, но сложно решить, а другое дело - это "моделировать реальность". Возвращаясь к тому, о чём был тред - если есть объект, под который, например, выделяется память, то не всегда вообще возможно пресказать (даже на момент запуска программы сколько этот объект будет жить, сколько ресурсов потреблять, и соответственно, где его рациональнее расположить в памяти...
И что?
Ты где-нибудь видел математическую модель,
использующую не функциональные зависимости,
а что-нибудь "объектно-ориентированное?"
---
"Я знаю правду! Все прежние правды --- прочь!"
Ты где-нибудь видел математическую модель,
использующую не функциональные зависимости,
а что-нибудь "объектно-ориентированное?"
---
"Я знаю правду! Все прежние правды --- прочь!"
Я видел. Я их сам даже иногда составляю.
Только ты, конечно, скажешь, что это нифига не математическая модель.
Это как раз тот самый "narrowness of imagination"
Только ты, конечно, скажешь, что это нифига не математическая модель.
Это как раз тот самый "narrowness of imagination"
> другое дело - это "моделировать реальность".
Как часто тебе приходилось моделировать реальность?
> не всегда вообще возможно предсказать
"Функциональщики" этим довольно успешно занимаются.
И может, надо прекратить заниматься откровенной ерундой,
повторяя за кем-то слова о невозможности что-либо сделать.
---
"Narrowness of experience leads to narrowness of imagination."
Как часто тебе приходилось моделировать реальность?
> не всегда вообще возможно предсказать
"Функциональщики" этим довольно успешно занимаются.
И может, надо прекратить заниматься откровенной ерундой,
повторяя за кем-то слова о невозможности что-либо сделать.
---
"Narrowness of experience leads to narrowness of imagination."
И что?
Ты пробовал составлять более математические модели,
функциональные и можешь убедительно показать, что и как.
---
"Narrowness of experience leads to narrowness of imagination."
Ты пробовал составлять более математические модели,
функциональные и можешь убедительно показать, что и как.
---
"Narrowness of experience leads to narrowness of imagination."
Посмотрел я, зачем нужен stddef.h.
О сях я был слишком хорошего мнения.
Оказывается, это ещё более убогий язык, чем я думал.
Только сейчас посмотрел зачем нужен <stddef.h>?
И ты еще споришь на тему языка C? Насколько я понял зачем нужен <stdint.h>, <limits.h>, <float.h>, и т.д. ты еще не посмотрел. Не говоря уже о том что стандарт в жизни своей не открывал.
> Только правильный термин не "C standalone environment",бугага
> а "C freestanding implementation".
> Впрочем по смыслу одно и то же.
То есть, ты отсылаешь к стандарту, которым сам не владеешь.
дословно наизусть не помню весь стандарт, если ты об этом.
"C hosted implementation" и "C freestanding implementation"Что стандарт открыть все же не решился, а словоблудие это призвание и работа. Или как?
никак не могут быть терминами из стандарта, потому что
термины стандарта вне стандарта вводятся через слово "standard".
Иначе это термины общего значения, и означают они ---
hosted & freestanding implementations resp.
Если очень нравится можешь добавлять слово "standard", а мне кажется вполне достаточным "C" (которое по определению ссылается на стандарт языка C). Кроме того насколько мне известно термины "hosted implementation" и "freestanding implementation" применительно к языку C нигде кроме стандарта не вводятся, поэтому двусмысленности накакой нет.
> У меня не было заявления, что "библиотека входит в язык",
> у меня было заявление, что стандартная библиотека языка C,
> которая описывается в стандарте языка C,
> является частью языка C.
То есть часть целого не входит в целое.
Ты думай, что пишешь-то!
Думай над тем что читаешь и не вырывай фразы из контекста.
> Не очень понял, что ты хотел сказать. http://en.wikipedia.org/wiki/POSIX
Ссылку ты привёл не самую лучшую. Всё таки у POSIX есть свой собственный первоисточник в интернете. Однако и из этой ссылки можно почерпнуть полезную информацию. А именно:
Стандарты POSIX развиваются. Кроме того, есть несколько отдельных стандартов, покрывающих отдельные куски функциональности ОС. Из всех Windows только NT прошла сертификацию на real-time extensions, и очевидно, что это было давно. Практической пользы на сегодняшний день от этого нет, но можно вот на форумах заявлять, что Windows соответствует POSIX. Умалчивая о какой виндовз речь и о каком именно стандарте POSIX речь, и какого года.
Ссылку ты привёл не самую лучшую. Всё таки у POSIX есть свой собственный первоисточник в интернете. Однако и из этой ссылки можно почерпнуть полезную информацию. А именно:
Стандарты POSIX развиваются. Кроме того, есть несколько отдельных стандартов, покрывающих отдельные куски функциональности ОС. Из всех Windows только NT прошла сертификацию на real-time extensions, и очевидно, что это было давно. Практической пользы на сегодняшний день от этого нет, но можно вот на форумах заявлять, что Windows соответствует POSIX. Умалчивая о какой виндовз речь и о каком именно стандарте POSIX речь, и какого года.
> другое дело - это "моделировать реальность".Хорошо, объекты в БД, с которыми постоянно идёт работа - этим тоже функциональщики занимаются?
Как часто тебе приходилось моделировать реальность?
> Только сейчас посмотрел зачем нужен <stddef.h>?
Да, потому что никогда раньше он мне нафиг не был нужен.
> Не говоря уже о том что стандарт в жизни своей не открывал.
У меня есть стандарт де-факто, мне хватает.
> а мне кажется вполне достаточным "C"
> (которое по определению ссылается на стандарт языка C).
А мне это не только не кажется, но ещё и вредно.
Потому что в твоём стандарте описано то, что не может существовать в условиях отсутствия файловой системы.
А в последнее время у меня наблюдается именно это.
И это именно си.
Но без заморочек с кучей заголовочных файлов.
И уж тем более --- со стандартной библиотекой,
которая не работает и даже бесполезна большей частью.
>>> У меня не было заявления, что "библиотека входит в язык",
>>> у меня было заявление, что стандартная библиотека языка C,
>>> которая описывается в стандарте языка C,
>>> является частью языка C.
>> То есть часть целого не входит в целое.
>> Ты думай, что пишешь-то!
> Думай над тем что читаешь и не вырывай фразы из контекста.
Я перечитал отмеченное тремя знаками ">" ещё раз.
Мне ещё раз повторить отмеченное двумя знаками?
---
"Студенту надо повторять всё три раза, Ганс. Три раза. Запомни, Ганс: три раза."
Да, потому что никогда раньше он мне нафиг не был нужен.
> Не говоря уже о том что стандарт в жизни своей не открывал.
У меня есть стандарт де-факто, мне хватает.
> а мне кажется вполне достаточным "C"
> (которое по определению ссылается на стандарт языка C).
А мне это не только не кажется, но ещё и вредно.
Потому что в твоём стандарте описано то, что не может существовать в условиях отсутствия файловой системы.
А в последнее время у меня наблюдается именно это.
И это именно си.
Но без заморочек с кучей заголовочных файлов.
И уж тем более --- со стандартной библиотекой,
которая не работает и даже бесполезна большей частью.
>>> У меня не было заявления, что "библиотека входит в язык",
>>> у меня было заявление, что стандартная библиотека языка C,
>>> которая описывается в стандарте языка C,
>>> является частью языка C.
>> То есть часть целого не входит в целое.
>> Ты думай, что пишешь-то!
> Думай над тем что читаешь и не вырывай фразы из контекста.
Я перечитал отмеченное тремя знаками ">" ещё раз.
Мне ещё раз повторить отмеченное двумя знаками?
---
"Студенту надо повторять всё три раза, Ганс. Три раза. Запомни, Ганс: три раза."
Не все БД функциональные, но то, что обычно требуется,
ложится на функциональную парадигму хорошо.
---
...Я работаю антинаучным аферистом...
ложится на функциональную парадигму хорошо.
---
...Я работаю антинаучным аферистом...
> Только сейчас посмотрел зачем нужен <stddef.h>?Ну а зачем тогда уже не первые сутки разговаривать о стандартной библиотеке C, если тебе о ней мало что известно и вообще она тебя не интересует?
Да, потому что никогда раньше он мне нафиг не был нужен.
> а мне кажется вполне достаточным "C"Это не мой стандарт
> (которое по определению ссылается на стандарт языка C).
А мне это не только не кажется, но ещё и вредно.
Потому что в твоём стандарте описано то, что не может существовать в условиях отсутствия файловой системы.
А в последнее время у меня наблюдается именно это.
И это именно си.
Но без заморочек с кучей заголовочных файлов.
И уж тем более --- со стандартной библиотекой,
которая не работает и даже бесполезна большей частью.
Это ANSI/ISO - они во всем виноваты.Но с тем фактом, что определением языка C является стандарт языка C, пожалуй стоит смириться.
Именно для случая отсутствия файловой системы и т.п. и придумана freestanding implementation. Если ты программируешь на C все же рекомендую почитать стандарт, ибо разработчики компиляторов именно на него опираются, не говоря уже о том, что станет понятно как писать портируемые программы (эти несколько заголовочных файлов freestanding implementation совсем не бесполезны, хотя функций вроде не содержат).
Я перечитал отмеченное тремя знаками ">" ещё раз.Ну зачем ты тут дурачка строишь?
Мне ещё раз повторить отмеченное двумя знаками?
Перечитай не то, что ты изволил вырвать из контекста, а оригинальный пост - весь абзац целиком.
Что за манера вообще в дискуссии вырывать фразы из контекста? Это что нервное?
Может мне твои посты раздробить на отдельные буковки, составить из них и запостить "Войну и мир", какую-нибудь?
> Ну а зачем тогда уже не первые сутки разговаривать о стандартной библиотеке C,
> если тебе о ней мало что известно и вообще она тебя не интересует?
Мне известно достаточно.
Внутренности libc я немного знаю.
> Но с тем фактом, что определением языка C является стандарт языка C,
Какой стандарт?
K&R --- это тоже стандарт.
> ибо разработчики компиляторов именно на него опираются,
Наглая ложь.
> не говоря уже о том, что станет понятно как писать портируемые программы
Я и без тебя знаю, что такого не может быть.
---
...Я работаю антинаучным аферистом...
> если тебе о ней мало что известно и вообще она тебя не интересует?
Мне известно достаточно.
Внутренности libc я немного знаю.
> Но с тем фактом, что определением языка C является стандарт языка C,
Какой стандарт?
K&R --- это тоже стандарт.
> ибо разработчики компиляторов именно на него опираются,
Наглая ложь.
> не говоря уже о том, что станет понятно как писать портируемые программы
Я и без тебя знаю, что такого не может быть.
---
...Я работаю антинаучным аферистом...
> Может мне твои посты раздробить на отдельные буковки,
> составить из них и запостить "Войну и мир", какую-нибудь?
Давай.
"Войну и мир."
Укажешь перестановку, с помощью которой ты этого добился.
Я проверю.
---
...Я работаю антинаучным аферистом...
> составить из них и запостить "Войну и мир", какую-нибудь?
Давай.
"Войну и мир."
Укажешь перестановку, с помощью которой ты этого добился.
Я проверю.
---
...Я работаю антинаучным аферистом...
Мне известно достаточно.ну конечно, только про stddef.h не знаешь почему-то? А про limits.h знаешь? (это гораздо интереснее stddef.h)
Внутренности libc я немного знаю.
Знание внутренностей libc не имеет отношения к знанию стандартной библиотеки. Если бы знал стандарт понимал бы это. В юниксовых libc помимо стандартной библиотеки разумеется поддержка POSIX API и прочих дополнительных расширений не говоря уже о том, что у каждой частной реализации есть своя специфика, а знание стандартной библиотеки подразумевает знание того, какая функциональность - стандартная, а какая - расширение.
Какой стандарт?Это не стандарт.
K&R --- это тоже стандарт.
Это 2 человека: Брайан Керниган и Деннис Риччи, которые кроме того, что оригинальные авторы языка, еще к тому же принимают участие в разработке стандарта. А второе издание их книги как раз описывает первый стандарт C 1989 года. (А первое издание этой же книги и является единственным "стандартом" K&R C).
> ибо разработчики компиляторов именно на него опираются,Ох ну как же я мог забыть про разработчиков, писавших компиляторы C в далекие 80е годы до выхода стандарта.
Наглая ложь.
> не говоря уже о том, что станет понятно как писать портируемые программы"Narrowness of experience leads to narrowness of imagination." (це)
Я и без тебя знаю, что такого не может быть.
> ну конечно, только про stddef.h не знаешь почему-то?
Он мне не нужен.
> А про limits.h знаешь? (это гораздо интереснее stddef.h)
Расскажи, зачем он мне нужен.
> Это не стандарт.
Де-факто стандарт --- тоже стандарт.
> Ох ну как же я мог забыть про разработчиков,
> писавших компиляторы C в далекие 80е годы
http://onboardc.sf.net
---
"Narrowness of experience leads to narrowness of imagination."
Он мне не нужен.
> А про limits.h знаешь? (это гораздо интереснее stddef.h)
Расскажи, зачем он мне нужен.
> Это не стандарт.
Де-факто стандарт --- тоже стандарт.
> Ох ну как же я мог забыть про разработчиков,
> писавших компиляторы C в далекие 80е годы
http://onboardc.sf.net
---
"Narrowness of experience leads to narrowness of imagination."
Кросс-платформенная программа:
Если серьезно. Почему-то не кросс-платформенный KOL для не кросс-платформенного Delphi генерирует .exe файлы размером порядка 30-50Kb, а такая же кросс-платформенная программа (с установкой widget type=win32) на кросс-платформенном Lazaurus для кросс-платформенного Free Pascal - 1.5Mb. Даже обычный RAD в Delphi в этом случае обходится размером 300-400Kb. Если бы разница не была столь велика, я бы окончательно перешел на Lazaurus...
Практика открытых проектов в интернете показывает, что скачанные исходники, как правило, не удается скомпилировать под windows (хотя авторы утверждают, что их программа переносима под windows). Приходится исправлять исходники, подбирать правильные значения параметров в конфигурационных .h файлах и.т.д. Так же разработчики открытых проектов частенько не осознают, что их программу будут компилировать в враждебной windows, на которой будет установлен лишь C/C++, а никаких интерпретаторов/компиляторов perl'a, ruby'a, python'a, nasm'a и никаких cygwin'ов не будет.
#ifndef WIN32
#error program requires Windows
#endif
#include <windows.h>
...
Если серьезно. Почему-то не кросс-платформенный KOL для не кросс-платформенного Delphi генерирует .exe файлы размером порядка 30-50Kb, а такая же кросс-платформенная программа (с установкой widget type=win32) на кросс-платформенном Lazaurus для кросс-платформенного Free Pascal - 1.5Mb. Даже обычный RAD в Delphi в этом случае обходится размером 300-400Kb. Если бы разница не была столь велика, я бы окончательно перешел на Lazaurus...
Практика открытых проектов в интернете показывает, что скачанные исходники, как правило, не удается скомпилировать под windows (хотя авторы утверждают, что их программа переносима под windows). Приходится исправлять исходники, подбирать правильные значения параметров в конфигурационных .h файлах и.т.д. Так же разработчики открытых проектов частенько не осознают, что их программу будут компилировать в враждебной windows, на которой будет установлен лишь C/C++, а никаких интерпретаторов/компиляторов perl'a, ruby'a, python'a, nasm'a и никаких cygwin'ов не будет.
Так же разработчики открытых проектов частенько не осознают, что их программу будут компилировать в враждебной windows, на которой будет установлен лишь C/C++, а никаких интерпретаторов/компиляторов perl'a, ruby'a, python'a, nasm'a и никаких cygwin'ов не будет.Не согласен. В любом случае необходимы какие-то библиотеки-обвязки, чтобы можно было работать платформенно-независимо с графикой, сообщениями, сетью и т.п. Поэтому просто компилятора заведомо не хватит на что-то отличное от консольного и несетевого - или программа должна содержать специфический для платформы код, или должны быть установлены дополнительные средства (библиотеки или что-либо ещё).
В любом случае необходимы какие-то библиотеки-обвязки, чтобы можно было работать платформенно-независимо с графикой, сообщениями, сетью и т.п.Для этого есть динамическая линковка.
А эти библиотеки - они тоже во всех ОС разные. Если ты, конечно, не содержишь в себе эмулятор ОС.
Оставить комментарий
Sharp
Ибо с самого начала надо учиться делать правильно.А то потом будет труднее переучиваться.
Вот так люди привыкают, что все всегда работает, что malloc и fopen всегда возвращает не NULL...
А если вдруг ихние программы попытаться запустить на другой машине, с другой архитектурой, с другой OC, то тогда можно выяснить, что и у int-а бывает разный размер, что функции getch просто нету, ровно как и библиотеки <conio.h>