Задачка на тему стек!

[незваный гость]

Есть надежный способ узнать - убрать #include <malloc.h> и попытаться скомпилировать. Возможны два исхода:
1) программа компилируется без warning'ов. Тогда скрипач (header) не нужен. (Возможно, прототипы есть в другом header'е. Или, и впрямь - не используются.);
2) компилятор шустро выдаст список неописанных функций.

Есть и другой метод, но он требует усилий. А именно - прочитать (и притом подробно) программу (якобы свою). И про каждую используемую функцию решить, где она описана - в этом ли же файле, али в header'е каком. И в каком именно. И что делает в Help'е посмотреть. Кстати, есть хорошее описание posix библиотеки в интернете: opengroup.org.

[Magistr]

А есть еще один способ, самый надежный: открыть соответствующий header и посмотреть что в нем написано.

[незваный гость]

В header нет, к сожалению, информации о том, какие из описанных функций использовались.

[Therion17]

Спасибо за ответ! (Я протормозил мог бы и сам догадаться!)

[bekas]

По-моему, пора уже давным-давно прикрыть эту лавочку (обсуждение задачи про стек).
Сколько можно говорить о такой пустячной программе, которая заняла у меня времени
всего десяток минут, а наговорили по ней уже на целую неделю...

[Therion17]

Большое спасибо за программку, но позвольте задать последний вопрос:
при компиляции, не знаю как у вас, у меня появляются 37 warnings с сообщением
"conversion may lose significant digits", и, например, в строке free(prior_formula[i].n1); выделяется точка, стоящая между словом prior_formula[i] и n1 красным цветом!

Подскажите как исправить данную проблему! Я пробовал заменить free(prior_formula[i].n1) на
free(prior_formula[i]->n1), но ничего не получается!

[bekas]

Замена free(prior_formula[i].n1) на free(prior_formula[i]->n1) говорит
о том, что вы не имеете четкого представления об операциях "." и "->"
Обязательно разберитесь с этим, это, как говорят у них в Одессе -
"две большие разницы". Я уж не говорю о том, что при такой замене вы должны
были получить уже не warning, а полноценный error.

Вы не говорите, в какой среде разработки у вас выполнялась компиляция.
У меня Visual Studio 6.0, там прототип free представлен примерно как

void free(void *)

Если у вас такой же прототип, то попробуйте "успокоить" компилятор
следующим образом:

free((void *)(prior_formula[i].n1))

А какого типа предупреждение было для free(prior_formula[i].n1)?

Вы говорите также о других 37 warnings, хотелось бы получить хоть
один оператор, который спровоцировал такое предупреждение.

Обычно такое предупреждение появляется при присваивании данному с меньшей
разрядностью данного с большей разрядностью, например:

char c;
long l;

c = l; // Здесь будет предупреждение
c = (char)(l); // Избавились от предупреждения

[Therion17]

Я пишу проги в компиляторе BORLAND C++ v 3.1! Вот по этому у меня и появляются эти ворнинги! Вот ещё пример ворнинга: при компиляции в операторе n1=out[d1]; он, почему-то
выделяет знак ";"

Подскажите пожалуйста как исправить прогу, чтобы этих ворнингов не было!

[PAV]

Therion17 писал(а):

Подскажите пожалуйста как исправить прогу, чтобы этих ворнингов не было!

Поменять настройки компилятора

[Therion17]

PAV писал(а):

Therion17 писал(а):

Подскажите пожалуйста как исправить прогу, чтобы этих ворнингов не было!

Поменять настройки компилятора

А вы можете подсказать куда нужно заходить и что менять ,просто я в этом плохо разбираюсь. Компилятор у меня BORLAND C++ v 3.1

[bekas]

На Borland я программировал очень давно и очень удивлен, что (российские?)
студенты изучают язык программирования C в этой версии (или это требование деканата?).
К сожалению, руководства по этой версии я уже выбросил - может быть там, как и
в Visual Studio, есть псевдооператор #pragma, который может подавлять warning?
А вообще-то, если вы хотите какой-то помощи, могли бы сообщить полностью
все сообщения компилятора. А так приходится гадать - что там у вас компилятор соорудил...

[незваный гость]

Замените long на int (всюду). Они здесь совсем не в тему. Индексы массивов все равно длинными быть не могут... Поэтому индексное выражение преобразуется в int с потерей значимости и выдачей предупреждения. Насколько я сумел понять Ваши примеры, это - основной источник. Хотя могут быть и другие.

Интересно, а почему были long написаны изначально? Должна же была быть какая-то мотивировка. И писать ведь лишнюю букву надо

[bekas]

Мотивировка простая - в Visual Studio int и long одного размера (32 бита), а вот
в некоторых версиях C размер int и long отличается, хотя long практически
везде (за исключением Java) занимает 32 разряда.

Товарищ (инициатор темы) ведь ничего не говорил о СРЕДЕ ПРОГРАММИРОВАНИЯ,
а только о программке...

А так что-то писать на все версии компиляторов - никакой жизни не хватит.
Хотя C и задумывался с благородной целью достижения мобильности программного
обеспечения, на самом деле даже внутри одной конторы-производителя
версии компиляторов могут быть несовместимы.

Например, практически все компиляторы (даже Java) неверно выполняют сдвиг
для некоторых величин сдвига переменных 64-разрядных типа LONGLONG...

[незваный гость]

С риском обмануть Вас, но я припоминаю, что на Solaris 8 long был 64-битным. В целом я не согласен с Вашей мотивировкой выбора типа. С типом (а не с длиной) связан набор операций. Хотим мы этого или нет, но индексация всегда int, равно как и сумма/разность указателей. И в printf(), и в alloc() возникает напряженка. А если игнорировать предупреждения компилятора, то влетаешь и вовсе в серое никуда - например, заказываешь 64K+1 памяти, а получаешь байт. И пялишься на экран в отладчике - в переменной все правильно, а буфер переполняется. И пока не перйдешь в ассемблер, не поймешь.

[bekas]

Речь у меня шла о МОБИЛЬНОСТИ программного обеспечения. Гораздо меньше риска
с переносом программ C с одной платформы на другие, имея данные long, а не int, которые
(int) очень часто эквивалентны short (16 разрядов, если следовать вашему примеру 64K + 1 как раз и дадут переполнение именно для short). Если у вас есть программа, для которой
целочисленные данные типа long, а не int, то хлопот с переносом намного уменьшится.
Особенно это актуально для структуры, когда эта структура наряду с явным обращением
к ее отдельным элементам может рассматриваться как сплошной поток байтов.
И вот тут, если у вас будет тип int, то наверняка программа не будет работать там,
где этот int эквивалентен short, а не long.

Недаром Мелкософт старается не использовать родные типы long или int, а для
пущей мобильности использует макросы DWORD, WORD и так далее...