sigmaN 0 27 января, 2016 Опубликовано 27 января, 2016 · Жалоба Ну вот это уже более развернутый ответ касающийся только printf а то сразу как можно реже пользуйтесь кейловскими(иаровскими) библиотечными функциями..как максимум-только malloc/free,все остальное заменяйте собственными реализациями Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 231 29 января, 2016 Опубликовано 29 января, 2016 · Жалоба Но проблема, если честно, не в самом объёме а в том, что это достаточно сильно меняющееся число. Ну и когда у вас несколько задач используют printf, то при анализе размеров стека понимаешь, что его надо увеличивать. В зависимости от сложности выводимой информации, народ указывает размеры до 2к. Вот и получается, что использование printf в трёх задачах - 6к озу. Применение своих п/п вывода экономит эту память. В моём случае скорости особой не требовалось, так как это происходило при выводе на дисплей, принтер, ну и в HTTP задаче. Никто не призывает отказываться от стандартных п/п. Просто надо знать инструмент, который применяешь. В случае с printf, надо автоматически увеличивать объём стека ну и убедится что вы выделили его достаточно. В многозадачной среде можно сделать переключение стека при вызове printf, естественно заблокировав его семафором. Тогда не нужно закладывать дополнительный объём стека для printf для каждой задачи. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 22 29 января, 2016 Опубликовано 29 января, 2016 · Жалоба В многозадачной среде можно сделать переключение стека при вызове printf, естественно заблокировав его семафором. Тогда не нужно закладывать дополнительный объём стека для printf для каждой задачи. Такие штуки лучше выносить в отдельный классы, методы, функции, делая защиту однозадачных вещей внутри в одном месте. Я использую отдельные классы-синглтоны, которые как бы везде видны, но существовать могут тока в одном экземпляре. В этом случае код не зависит от способа вывода служебной информации - где послед. порт, где сам экран, где эзернет и т.д. Позволяет дать имена более осмысленные и соответствущие требованиям конторы, чем некий prinf и им подобные наборы букв )) Тогда код легко читаем и переносим. Копированием кусков с одного проекта в другой не требует их допиливания. Не нужно писать бессмысленные комменты, которые тока путают. У меня в коде комментов практически нет - код написан так, что легко вкурить что он делает даже через много месяцев... Сорри за офф )) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 29 января, 2016 Опубликовано 29 января, 2016 · Жалоба Такие штуки лучше выносить в отдельный классы, методы, функции, делая защиту однозадачных вещей внутри в одном месте. Я использую отдельные классы-синглтоны, .... Оверинженеринг в вакууме. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Johnny81 0 29 января, 2016 Опубликовано 29 января, 2016 · Жалоба Оверинженеринг в вакууме. Да ладно, это вы Явы не видели :) Вот там оверинжиниринг в полный рост. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 22 29 января, 2016 Опубликовано 29 января, 2016 · Жалоба Оверинженеринг в вакууме. Когда ушел в C++ на ARMах, в голый С не вернусь даже под дулом пистолета ))) Разница по размеру кода щас никого не волнует, да и нету там особой разныцы, зато читаемость и переносимость на порядки выше! Скорость работы тоже не страдает. Я не использую исключения и работу с ними (пока что). В обязательном порядке стоит ось, причем сделана обертка вокруг нее, чтобы она стала C++, ну, там классы потоков, программных таймеров, семафором и т.п. Поменяю ось, поменяю обертку под нее, а весь остальной код во всех проектах вообще не изменится. Так читаемость и переносимость кода возрастает в разы. Нет глубокой привязки ни к ядру, ни к процу, ни к компилятору, ни к оси. Экономия времени на новых проектах просто чумовая! Лень-матушка вынуждает так поступать - категорически ненавижу переделывать свою же работу, лучше сразу сделать нормально ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 29 января, 2016 Опубликовано 29 января, 2016 · Жалоба Поменяю ось, поменяю обертку под нее, а весь остальной код во всех проектах вообще не изменится. Это и старый добрый Си умеет. Вам нравится Си++ - почему бы и нет? Может быть, у меня просто такие проекты, но ни разу не ощущал потребности перейти на Си++. А просто так без причины как-то не хочется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 22 29 января, 2016 Опубликовано 29 января, 2016 · Жалоба Это и старый добрый Си умеет.Это даже можно на асме сделать )) Тока переход в плюсы - это переход на новый уровень структурного, а не функционального программирования. Чистый С хоть и позволяет это делать, но с такими ацкими костылями, что боже упаси это недобровольный "секас" Вам нравится Си++ - почему бы и нет? Может быть, у меня просто такие проекты, но ни разу не ощущал потребности перейти на Си++. А просто так без причины как-то не хочется. Дело тут вовсе не том что нравится или нет, а в том, что этот инструмент обладает гораздо бОльшей функциональностью и значительно упрощает создание самодокументируемого и легкосопровождаемого кода. Мне важнее последнее. Ведь в конечном итоге любой код превращается компилятором в т.н. машинные коды. Поэтому если когда-то появится возможность писать на ARM под С#, я буду это делать, предварительно отключив "тяжелые" вещи, свойственные этим мощным языкам. Я не буду ручной дрелью ковырять сотню дырок, особенно когда под рукой есть электрическая дрель ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Johnny81 0 29 января, 2016 Опубликовано 29 января, 2016 · Жалоба Поэтому если когда-то появится возможность писать на ARM под С#, я буду это делать, предварительно отключив "тяжелые" вещи, свойственные этим мощным языкам. Шарп без тяжелых вещей будет хуже плюсов ;) банально потому, что в плюсах значительно больше инструментов времени компиляции. Те же шаблоны, лямбды (сахарок над шаблонами), итераторы в for, да хоть старые добрые макросы. А вот в шарпе приоритет отдается динамике. Опять же очень многие вещи завязаны на GC. Плюсы же дают возможность писать достаточно высокоуровнево, но там где надо - генерируемый код будет не медленее си Хотя конечно процессоры развиваются и постепенно это будет волновать все меньшее количество людей :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 22 29 января, 2016 Опубликовано 29 января, 2016 · Жалоба Хотя конечно процессоры развиваются и постепенно это будет волновать все меньшее количество людей :)Именно! Тут главное - не отставать от поезда, иначе быстро спишут в утиль Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 29 января, 2016 Опубликовано 29 января, 2016 · Жалоба Именно! Тут главное - не отставать от поезда, иначе быстро спишут в утиль Всё-таки чистое программирование и ковыряние в железе - сильно отличающиеся области деятельности. ИМХО, Си - достаточно простой и обозримый язык, чтобы железячник мог им достойно овладеть и строить сложные системы. Си++ уже выползает за пределы этой зоны, такие железячники - уже редкий зверь (вроде Вас). Там, где железо и софт делает один человек, Си никуда не денется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 22 29 января, 2016 Опубликовано 29 января, 2016 · Жалоба Всё-таки чистое программирование и ковыряние в железе - сильно отличающиеся области деятельности. ИМХО, Си - достаточно простой и обозримый язык, чтобы железячник мог им достойно овладеть и строить сложные системы. Си++ уже выползает за пределы этой зоны, такие железячники - уже редкий зверь (вроде Вас). Там, где железо и софт делает один человек, Си никуда не денется. Все это перешло в глубокий офф, ибо холивар - "C vs C++" - пожалуй самый бессмысленный и беспощадный холивар у программеров. Одно время был "ASM vs C", я чуток застал те дремучие времена такого холивара (я про контроллеры, т.е. эмбеддерство, НЕ ПК), тоже самое )) Придет время, C# или что-то подобное сменит C++.... Короче, вот простое сравнение: Детишки носятся на велосипедах, подрастают и пересаживаются на мопеды/моциклеты, потом личное авто, а у более успешных личный самолет :) Чистый С - это велосипед: для здоровья полезен, укрепляет мышцы, прост как 5копеек - починит даже безрукий. Но далеко на нем не уедешь и тем более не увезешь. Но другое дело - моциклет и т.д ..... Понимаете о чем? ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Johnny81 0 29 января, 2016 Опубликовано 29 января, 2016 · Жалоба Чистый С - это велосипед: для здоровья полезен, укрепляет мышцы, прост как 5копеек - починит даже безрукий. Но далеко на нем не уедешь и тем более не увезешь. Это не совсем так, достаточно взглянуть на ядро линукса. На чистом Си вполне можно замутить много чего, а если использовать макры или даже внешний препроцессор - то возможности открываются колоссальные :) То же ООП вполне себе работает и в сях, просто местами оно похоже на закат солнца вручную :) Чистый Си как-то практически остановился в развитии. Особенно это хорошо видно, если сравнить его с плюсами. Плюсы заморозились в промежутке 1998-2011. Однако стандарт 2011 дал уже много вкусностей, сейчас есть стандарт 14, в котором часть вкусностей углубили. Дальше речь идет о стандарте 17, в котором это движение продолжается. В Си же за последние годы было добавлено крайне мало - навскидку атомики, bcd, может еще что по мелочи. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 22 29 января, 2016 Опубликовано 29 января, 2016 · Жалоба достаточно взглянуть на ядро линуксаОй не надо, я тока что пообедал То же ООП вполне себе работает и в сях, просто местами оно похоже на закат солнца вручнуюЭто точно! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 29 января, 2016 Опубликовано 29 января, 2016 · Жалоба Видимо, речь идет про конкретный случай. Меня писать свой printf как-то не климатит... На самом деле не так сложно. Правда если использовать более базовые функции из библотеки. Я делал принты через TCP и UDP -- познакомился. Все это перешло в глубокий офф, ибо холивар - "C vs C++" - пожалуй самый бессмысленный и беспощадный холивар у программеров. Одно время был "ASM vs C", я чуток застал те дремучие времена такого холивара (я про контроллеры, т.е. эмбеддерство, НЕ ПК), тоже самое )) Придет время, C# или что-то подобное сменит C++.... Короче, вот простое сравнение: Детишки носятся на велосипедах, подрастают и пересаживаются на мопеды/моциклеты, потом личное авто, а у более успешных личный самолет :) Чистый С - это велосипед: для здоровья полезен, укрепляет мышцы, прост как 5копеек - починит даже безрукий. Но далеко на нем не уедешь и тем более не увезешь. Но другое дело - моциклет и т.д ..... Понимаете о чем? ;) Нет не понимаю. На Javа предлагаете писать или ХML, а может на Rational Rose? Все это перешло в глубокий офф, ибо холивар - "C vs C++" - пожалуй самый бессмысленный и беспощадный холивар у программеров. Одно время был "ASM vs C", я чуток застал те дремучие времена такого холивара (я про контроллеры, т.е. эмбеддерство, НЕ ПК), тоже самое )) Придет время, C# или что-то подобное сменит C++.... Короче, вот простое сравнение: Детишки носятся на велосипедах, подрастают и пересаживаются на мопеды/моциклеты, потом личное авто, а у более успешных личный самолет :) Чистый С - это велосипед: для здоровья полезен, укрепляет мышцы, прост как 5копеек - починит даже безрукий. Но далеко на нем не уедешь и тем более не увезешь. Но другое дело - моциклет и т.д ..... Понимаете о чем? ;) Да нет никакого холивара. Тот же компилятор для С++ написан на С. Только если писать апликации, то конечно С++ кроет С, а вот с системным программированием пока все с точностью до наоборот. У часового мастера и у кузнеца разные инструменты. Ой не надо, я тока что пообедал Это точно! От вас подвигов никто и не ждет. Есть же мы для этого :) Однажды у меня был один сотрудник, который писал на Вижуал С. Он к эмбеддед программистам приставал, чтобы признали, что на РС тоже реал-тайм можно писать. С ним соглашались, чтобы отстал. И с вами согласимся. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться