Цитата(zltigo @ Aug 10 2016, 18:53)
Из личного стиля и опыта - много легче. Одно дело, когда те же задачи имеют типично имеют по несколько переменных да несколько вызовов. Понятно, что стек расходуется немного, пиковых нагрузок нет, ну и выделил с небольшим запасом, на этипе тестирования можно и побольше запас сделать и последить за расходом. Если стеки начнут потреблять память сотнями байт при вызове разных функций в произвольные моменты, то тогда уже начнет маячить нехватка памяти, желание урезать стеки по максимуму и начать бороться с возможными последстиями.
Во-во! А у нас в некоторых задачах по нескольку КБ стеки уже. Не в моих задачах - я стараюсь экономить память. Но я не один участвую в проекте.
Это хорошо как Вы пишете распланировать когда ты сам себе хозяин и только один пишешь ПО.
Но как трудно объяснить людям почему нежелательно использовать sprintf() или что, если например внутри switch в одном case на стеке используется временная структура1, а в другом - временная структура2, по неск. десятков байт каждая, то очень желательно их объединить в union. Ну и т.п.
И что ещё - хорошо, например сейчас определили, что в задаче1 вызывается такая-то функция, которая ест много стека. Хорошо - выделили этой задаче побольше. Но потом, когда уже подзабыли немного, что эта функция много ест при определённых условиях, и сделали её вызов из другой задачи2, имеющей мало стека. И писал эту функцию совсем другой человек. И отладили, проверили - всё ок, работает ок. А ведь эта функция много ест стека только при определённых редких условиях и на этапе отладки эта ветка выполнения кода не случилась, а вылезет оно потом много позже и неожиданно.
Вот поэтому и очень желательно иметь такой механизм контроля стека, который можно просто включить, когда возникают хоть малейшие подозрения, когда прога ведёт себя как-то неадекватно и подозрительно. И чтобы не надо было лазить вручную проверяя каждый стек или ставя какие-то watchpoint-ы то на один стек, то на другой - трудоёмко это и трудно будет локализовать место проблемы.
