возврат из подпрограмм

Hi George,

Mon Jun 19 2006 10:16, George Shepelev wrote to Michael Zaichenko:

MZ>> Hе всегда так просто.

GS> Конечно не всегда.

GS> Hо в большой и сложной системе надо пытаться диагностировать максимально GS> возможное число неисправностей. Иначе поддерживать её в рабочем состоянии GS> будет слишком сложно и дорого... А то я не знал :)))

GS>>> А зачем "менять камень"? Из вредности? MZ>> Затем что его сняли с производства. GS> Выбирать надо то, что не снимут с производства или чему несложно найти Hе я выбирал этого глюка. Это было 9 лет назад...

GS> полноценную замену. Погляди к примеру в сторону PIC'ов, там с этим GS> проблем нет. А зачем мне ПИК? Мне 4 катушки по 4 ампера каждя ШИМить надо, потребление контроллера не волнует. В производстве уже идут АВРы, и делаться будет на них. Под них есть все. И наработки. Есно на си, под АВР я еще ни строчки на асме не написал и не собираюсь.

MZ>> Дешевле написать на си с нуля, и развести новую плату.

GS> Кто тебе сказал, что дешевле? Это время и деньги на перепроектирование А мы калькулятор взяли и посчитали, однако.

GS> и повторное тестирование и отладку (которые, кстати, нельзя начать GS> раньше, GS> чем новый вариант платы изготовят). Hа не слишком больших тиражах или Можно взять похожую плату. 3 катушки ШИМит , идет в другом изделии.

GS> при жёстких сроках это может "утопить" весь проект... Hа это время есть запас старых плат.

Плату уже развели, нарисовали в трехмерке, покрутили в модели изделия, ляпота...

GS> Георгий

WBR, Michael.

Hello Michael.

Mon Jun 19 2006 23:43, Michael Zaichenko wrote to me:

DO>>>> маленький). MZ>>> Угу, плюс для маленьких поделок и минус для серьезных вещей.

DT>> Эт' почему? В Аде примерно так же. MZ> Серьезные вещи как правило не пишутся в одиночку. MZ> Как правило несколько языков, сторонние покупные библиотеки. MZ> При этом под каждую версию паскаля надо иметь либо исходники и строить MZ> либы самому либо иметь кучу либов. Потом есть у тебя некий TPU, MZ> а к нему документация должна быть. У си есть инклуд, кторый MZ> наврядли забыли поправить.

Это ты уже рассказываешь про недостатки _реализации_, с определёнными натяжками. Сказал бы - "не люблю", и всё. :)

DT>> Вот меня, например, в C/C++ раздражает необходимость иметь и синхронно DT>> править исходники, файлы заголовков да ещё и make-файлы (хорошо хоть DT>> IAR-овская IDE сама умеет проект строить). Я, кстати, в сишный DT>> исходник MZ> IAR-овская IDE кстати далеко не фонтан.

Как редактор - да, я MED-ом пользуюсь. А проект строить нормально умеет. Hу и отладчик неплохой при наличии JTAG-а.

MZ> Применительно к эхотагу uVision3 от кейла несравнимо приятней.

Возможно, не видел. Как я понимаю, Кейл не поддерживает такого количества платформ, как IAR, а работать с одним языком и одной оболочкой с разными кристаллами очень удобно.

DT>> вставляю "интерфейсную секцию", вроде паскалевской, а потом DT>> специальной приблудой выделяю её в h-файл. MZ> А зачем? H файл не часто меняется.

Когда пишешь модуль, править надо параллельно: написал функцию - впиши заголовок в H-файл. А у меня всё в одном файле, заголовки, одноимённые моим модулям, создаются автоматически и являются чисто техническими файлами.

DT>> А с функциональными языками дела не имел? Я пытался интересоваться :) DT>> - но как-то не очень пошло. MZ> Hаверно нет, или я не помню что это за звери.

Hапример, Caml/O'Caml, Haskell. Собственно, лисп и форт тоже близки к функциональным языкам, только они "нечистые", суть идеи по ним понять сложно. :)

Dimmy.

Hello Olga.

Tue Jun 20 2006 00:10, Olga Nonova wrote to Dmitry Fedorov:

ON> Вернее можно, если забыть про классы, наследования, полиморфизмы и ON> прочие штучки-дрючки обьектного программирования. А когда с ON> С++ ты это не используешь, он становится обычным С без плюсов.

Hе совсем. Есть в плюсах приятные "необъектные" фичи. Часть которых, впрочем, перенесена в стандарт C99 или как его там, но не все компиляторы его поддерживают.

Dimmy.

Hi Dmitry !

Совсем недавно 19 Jun 06 10:01, Dmitry Orlov писал к Kirill Frolov:

KF>> В вашем Израиле -- за "услугу тонового набора" тоже денег KF>> берут?

DO> Конечно, в виде абонентской платы. От типа набора она правда не DO> зависит, как afaik и от передачи caller id. А у нас за CallerID отдельную деньгу берут. Отдельная платная услуга.

WBRgrds Ruslan

Hi Vladimir !

Совсем недавно 19 Jun 06 17:28, Vladimir Vassilevsky писал к Ruslan Mohniuc:

RM>> Вот скажи, ты когда плавающую точку (IEE754) на асме применяешь, RM>> неужто сам все с нуля писал, или все-таки взял готовый аппнот от RM>> мелкочипа? Я, например, взял готовый.

VV> В написании плавучки на асме нет ничего особенно сложного, если VV> понимаешь, что такое плавающая точка. Я понимаю. Сначала разобрался, потом свое писал, потом увидел, как это еще оптимальнее сделать- взять готовое, уже написанное и соптимизированное под конкретную архитектуру. Вот мне и стало интересно, GS подобные вещи всегда сам с нуля пришет, так как принципиально ни в грош не ставит написанное окружающими (например, те же аппноты).

RM>> PS только не говори мне, что всегда без плавучки обходился. Еще RM>> скажи, что базы данных никогда не писал и краткие базы ключей для RM>> ускорения поиска по основным базам никогда не строил. Я RM>> разумеется про асм и майкрочип. Парочка таких задач тебя бы RM>> быстро к ЯВУ развернула.

VV> Когда пишешь большие проекты на асме, то волей-неволей превращаешься VV> в компиллятор. Сначала программа превращается в последовательность VV> call-ов, потом появляются формальные соглашения на вызовы, а потом VV> обьекты с методами. О низкоуровневой оптимизации приходится забыть. VV> Так, спрашивается, зачем изображать из себя компилер, если есть VV> готовый? Вот и я о том же. Hо пишу это все скорее не для GS, а для тех, кто его письма может прочитать и углубиться именно в это низкоуровневое программирование.

WBRgrds Ruslan

Привет Shapovalov!

SI> Это к тому, что этот "недостаток младших Пиков" почему то на АВРках не SI> мешает наличию С.

Это и ПИКам не мешает. Мешает только Георгию.

С уважением, Andrey 20 Июн 06 года

Здравствуйте

George Shepelev пишет:

Это к тому, что этот "недостаток младших Пиков" почему то на АВРках не мешает наличию С. С уважением, Шаповалов Алексей

Здравствуйте

George Shepelev пишет:

Почему теоризирую. Было сделано (не мной) на С на какой-то АТ89Схх. Частота 24 МГц. Асмовских вставок не было. С уважением, Шаповалов Алексей

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, George Shepelev! You wrote in conference fido7.ru.embedded to Jurgis Armanavichius on Mon, 19 Jun 2006 09:23:24 +0400:

GS> Делюсь опытом дальше, в необслуживаемых системах я вставлял код, GS> периодически восстанавливающий значение большинства регистров GS> конфигурации.

Жора, количеству сделанных тобой глупостей просто нет числа.

dima

Здравствуй, George!

Как то 19 Jun 06 в 10:23, George Shepelev писал Jurgis Armanavichius:

GS> Делюсь опытом дальше, в необслуживаемых системах я вставлял код, GS> периодически восстанавливающий значение большинства регистров GS> конфигурации. А поподробнее, плиз! Что за контроллер и сколько времени длится 'период необслуживаемости'? :) А почему это стало необходимо - начинало глюкавить? Я сейчас именно над таким вопросом думаю. GS> Георгий Пока! Pasha

rа4аrb@rаmblеr.ru

_*NO CARRIER*_ Now playing: silence (Winamp is _dead_)

Мой софт работает. Все стандартные свойства последовательного интерфейса -- поддерживаются. Не поддерживается только полная эмуляция PC-совместимого чипа (16550A).

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ я вот на что хочу обратить внимание

1. закончиться нормально.
2. дать fail.
3. вызвать исключение.

Итого -- 3. Чем, интересно, fail отличается от исключения?

В конечном итоге описываешь автомат. Реализуемый достаточно просто на чём угодно. Пока число состояний и условий переходов не велико.

А зачем вообще исключения? Исключение -- это удобный способ обработки ИСКЛЮЧИТЕЛЬНЫХ ситуаций. В эхотажной области любая исключительная ситуация -- штатная.

Увы. Ничего не понимаю в прологе.

Но почему-то кажется, в C подобное реализовать не сложно. Путём проверки валидности, например, до возврата из функции предиката, в отдельной функции. Для доступа к локальным переменным вызываемой функции GCC предоставляет такую удобную вещь как вложенные функции. В C++ можно всё обозвать объектами, да и стеки в STL есть... Я не хочу сказать, что всё мол стоит писать на C. Верю на слово, в prolog-е будет лучше, наверное.

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Olga Nonova! You wrote in conference fido7.ru.embedded to Jurgis Armanavichius on Mon, 19 Jun 2006 20:29:42 +0000 (UTC):

ON> Здравствуйте, Уважаемый Jurgis!

ON> Sun Jun 18 2006 22:00, Jurgis Armanavichius wrote to Dimmy ON> Timchenko:

JA>> Вообще-то, написание понятных и ясных программ от языка не зависит. JA>> Можно и на ЯВУ написать непонятную программу (коллега Георгий JA>> говорит, что на ЯВУ это сделать даже проще!)

ON> Hеужели люди не замечают, как лихо Вы передергиваете слова ON> оппонента?

Нет, никто кроме вас ничего не передергивает. Жора никаких ЯВУ не знает, ваш коллектив впрочем тоже.

ON> Утверждалось, что ТОЛЬКО С провоцирует на пацанство и разгильдяйство ON> в программировании.

Не более, чем другие подобные языки.

ON> А Вы приписали Геогию тезис, что все ЯВУ -источник разгильдяйства! ON> Hекрасиво, Юргис, делать такие подмены, да еще и сдабривать их ON> омерзительными смайликами. Вот, например, Паскаль- тоже ведь ЯВУ.

И столь же, если не больше, подвержен разгильдяйству и грязному хакерству.

ON> Hо он не только не провоцирует на пацанское поведение, а наоборот- обрубает ON> шаловливые рученки и буйство мысли, столь пагубное для занятий ембедой.

Просто вы ни того ни другого не знаете и не умеете использовать.

dima

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Olga Nonova! You wrote in conference fido7.ru.embedded to Igor Ulanov on Mon, 19 Jun 2006 20:45:38

GS>>> Ты не по адресу. "Ложные обобщения" делали те, кто кричат в эхе GS>>> "си - панацея!"

IU>> Ложные обощения делают все. А ложные они потому, что обобщения. IU>> "Си-панацея" - ложь, "лучше писать на ассемблере" - тоже ложь. Ложь IU>> потому, что это попытка обощить узкий частный опыт. Тебе на IU>> ассемблере удобно писать - отлично. Мне не удобно. И как нам IU>> увязать эти два частных субъективных мнения основанных на нашем IU>> опыте?

ON> А и не надо ничего увязывать! Эху читают много непишущих и свежих в

Эху вообще мало кто читает.

ON> ембеде людей.

Это портрет вашего коллектива - много несведущих людей.

ON> Hаша задача- не дать закрепиться этому дутому мифу в мозгах ON> подрастающего поколения.

Ваша задача - флейм.

dima

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Michael Zaichenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 20 Jun

DO>> Дело не в размере, а именно в гибкости, в сопряжении с кодом на DO>> других языках, etc. Размер как раз в рамках архитектуры ограничен DO>> не был (то есть только самой архитектурой).

MZ> А зачем нужна гибкость и споряжение с другими языками для поделок?

Почему поделок-то?

MZ> Я под размером не имел ввиду размер в байтах. MZ> ...Ваще, у меня на борланд алергия, паскаль ненавижу :)

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

MZ>>>>> Разве что если приспичит подключить к оболочке модуль написаный MZ>>>>> на хитром языке. Исодники на msvc,bc,ibmc можно было прицеплять MZ>>>>> без проблем.

DO>>>> Прямо исходники? И он компилирует с учетом всех расширений DO>>>> указанных компиляторов, или все же собранные объектники?

MZ> Hе сам компилирурует, а вызывает сторонний компайлер. MZ> Поидее ты можешь поправить правило сборки и припаять хоть свой MZ> компилер с своего языка.

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

MZ>>> Hу с обьктниками и либами ваще никаких проблем. DO>> Hу наверное все же соглашения о вызовах надо согласовывать, куда ж DO>> без этого...

MZ> Дык прологу пофигу, ему расскажи что за функции и какие у них MZ> соглашения.

Для того, чтобы это рассказать, в этом прийдется разобраться, функции прийдется соответственно оформить (как stdcall например). Нет никакой разницы с турбопаскалем или любой другой системой.

MZ>>> А исходники раньше мог, только нужно было в свойсвах проекта MZ>>> указать компилятор. Причем можно было даже делать всю прогорамму MZ>>> на си, со

DO>> Он что сам компилировал, или вызывал все же компилятор?

MZ> В чистом виде си он не понимает вообще. MZ> Единица компиляции (модуль) может быть либо чисто прологовской либо MZ> сишной. Hо ты можешь в прологовском проекте написать сишный модуль с MZ> main функцией. А в свойствах проекта скать что мэйн у тебя сишний. MZ> Получается сишный проект с прологовскими вставками :)

Ничего удивительного в этом нет, вопрос в том какие это дает преимущества. Плюс к этому, наверняка прийдется тащить в такой проект обе системные библиотеки.

MZ> Поэтому считаем что технической проблемы писать на смеси си-пролог MZ> нет и небыло.

Проблемы всегда есть, приходится разбираться в соглашениях о вызовах и тому подобных неязыковых деталях, но они при этом такие же, как и для любого другого смешанного использования языков.

MZ>>> Вопрос как - это зависит от опыта. Hа практике решали задачи MZ>>> управления в достаточно ответсвенных местах. Примеров не будет - MZ>>> NDA

DO>> Hу NDA позволяет привести примеры. Я же не прошу точного назначения DO>> и места. Хотелось бы понять для каких задач это может быть полезно DO>> и чем лучше более традиционных средств.

MZ> Маршрутизация авиалиний в крупном аэропорте. MZ> Hекие автоматизации на атомных станциях. Про эту часть я почти MZ> ничего не знаю. MZ> Экспертная система(заказная) для планирования и моделирования MZ> бизнесс процессов. К ней я имел некое отношение - реализация MZ> подобного проекта на си 1000 человеко-лет наверно, короче не MZ> реализуемо. MZ> Экспертные системы для медицины. MZ> Это были примеры серьезных проектов. в одиночку не решаемых либо MZ> решаемых долго.

Понятно, к встраиваемым системам это если и относится, то весьма далеко от тех, что обычно тут обсуждаются.

MZ> теперь еще попроще. MZ> По уходу с конторы с приятелем взяли заказ на экспертную систему. MZ> Я полность написал ядро, он делал остальное. Hу и эксперт потом MZ> привлекался, для тестирования и заполнения знаниями. MZ> По вечерам, за месяц с небольшим, _с_нуля_, мы сделали коммерческий MZ> продукт. MZ> С серьезным тестированием на пачке компов и пачке виндов, MZ> руководством, сохранением результатов в пожатой базе... MZ> Как такое реализовать на си, хоть с мешком плюсов, с нуля, за два MZ> человеко-месяца?

Наверное никак, я не знаю, но это уже совсем к embedded не относится.

MZ>>> Применительно к управлению. MZ>>> У тебя есть некий обьект, например лампочка.

DO>> О. У меня именно этот объект и есть.

MZ> Hу хорошо, пусть ты обмерил автоматом параметр у горы лампочек. MZ> Hа прологе нет проблемы написать прогу которая соберет тебе эти MZ> лампочки в максимально близкие пары хоть по 10 параметров. MZ> Добавить 11 параметр еще проще. Можешь разные эфристики применять, MZ> искать лучшее.

Но передо мной никогда не стояло подобных задач, мне надо заданную мощность скормить лампе, а не отбирать их по параметрам.

MZ>>> Дальше твоя программа должна анализировать эти три состояния и MZ>>> принимать решения. MZ>>> в случае с си тебе придется после вызова написать пачку ифов или MZ>>> switch/case.

DO>> Я обычно делаю state-mashine переменная state которого принимает DO>> разные значения (и их куда больше трех) плюс иногда есть еще DO>> дополнительные переменные, уточняющие состояние, в основном для DO>> диагностики, на ход программы они не влияют.

MZ> Hет проблем. на си я тоже так делаю. MZ> Hа прологе как правило не нужны стейт машины.

Можно конечно состояние хранить не явно, а так сказать точкой в программе, только мне явно - удобнее.

MZ>>> А на прологе не нужно. MZ>>> Любой предикат может закончится нормально, дать фэйл, или вызвать MZ>>> исключение.

DO>> А если fail и/или exeption невозможны?

MZ> Hу, ты сам пишешь предикат. будет он давать фейл или нет - зависит MZ> от тебя. просто эксепшен это обычно плохо, а фейл это нормально. MZ> Hаверно проще представит это другим макаром.

MZ> Сишная программа имеет один стек вызовов. ++ пока не рассматриваем.

Да вообще-то сколько нужно, столько и имеет. Это процессор может иметь один аппаратный стек вызовов, а может вовсе никаких стеков не иметь.

MZ> Пролог имеет сразу три стека call stack, back track, trap track.

Мне не очень понятно что это дает в плане задач управления.

MZ>>> А вот как это выглядит на прологе. DO>> То есть обработка исключений готова. А еще что? MZ> да просто море всего. MZ> родной тип данных для пролога - список.

Ну а куда мне этот список притулить? Мне регулировать надо, а не списки обрабатывать.

MZ> список может быыть из чего угодно. даже из списка.

MZ> определяем домены

MZ> color = integer color_list = color* MZ> device = lamp(color);

Цвет лампы у меня зависит от того что туда химики на заводе намешали...

MZ> теперь я могу легко работать с данными опускаять на любой уровень. MZ> добавим хранилище facts - dev % MZ> devices_db(device) MZ> again_dev(device_list)

MZ> скинуть базу в файл или зачитать - save/2 consult/2 добавить/убавить MZ> факт assert/retract/retractall

И файлов никаких и близко нет. То есть ну совсем другие задачи.

MZ> соответсвенно мы плучается вызываем на выполнение данные. MZ> Или что более правильно, больше нет разницы между кодом и данными. MZ> Можно делать самомодифицирующийся код.

Хорошо, что можно, зачем только? Только имея код в ПЗУ, а данных несколько сот байт особо не помодифицируешь.

MZ> Можно при помощи save и consult выгружать код в файл, менять его, MZ> загружать обратно. MZ> Получаем возможность изменения кода в откомпилированой программе, MZ> без перекомпиляции. Интерпретатор со скоростью компилированого :)

Хочется спросить какова же скорость компилированного?

MZ> По научному это называетмя метапрограмированием.

MZ> Рекурсия - тоже родное свойство пролога. собсно список - рекурсивный MZ> тип данных. Реурсию пролог может оптимизировить, вырождая в цикл и MZ> не потребляя при этом стек...

Это хорошо, но как-то я без рекурсий в управляющих программах обхожусь.

MZ> Hу на закуску практический пример, как за 5 минут можно написать MZ> нечто полезное, в стиле райтонли. MZ> Мне захотелось узнать цену микрофарады для разных банок разных MZ> производителей - --- cut here facts % определяем базу с ценами на MZ> кондеры a(string,integer,integer)

Да где ж ты их возьмешь, эти цены? Это же не нечно постоянное, это зависит от кучи обстоятельств.

dima

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Michael Zaichenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 20 Jun

DT>>>> Эт' почему? В Аде примерно так же. MZ>>> Серьезные вещи как правило не пишутся в одиночку.

DO>> Hет никаких проблем с этим в ТР. Подверждение тому - куча готовых DO>> кем-то написанных библиотек.

MZ> В 91ом году на си было не в пример больше интересных библиотек. MZ> Как и сейчас. Достаточно купить компакт из серии всякая хрень для MZ> программера и посмотреть какие есть либы для си и какие для дельфей.

Сейчас я очень далек от темы, а в середине девяностых для Паскаля было больше, или хотя бы доступней. Были Турбо, Обжект, Асинк профешинал от ТурбоПавер, был ТурбоВижн борландовский - и их сишные аналоги появились позже и портировались с паскаля.

MZ>>> Как правило несколько языков, сторонние покупные библиотеки.

DO>> И?

MZ> А как подружить турбо паскаль с турбо прологом?

Не знаю.

MZ> Или турбо паскаль с турбо си?

Запросто, ТР линкует стандартные obj.

MZ> Турбо си с турбо прологом вроде дружились. MZ> В те далекие годы и с ассемблером подружить было не просто, вагон MZ> ограничений.

Никаких ограничений, тем более, что в ТР первым появился достаточно мощный встроенный ассемблер.

MZ> И накой ваще этот tp сдался?

Быстрый удобный компилятор с удачного надмножества паскаля.

MZ> Как пример идеи с реализацией stony brook pascal был гораздо MZ> интересней, поскольку работал с нормальными обьектниками.

Это была во-первых, реализация языка, придуманного в Борланде. Во-вторых, при всех наворотах, реализация худшая. Несмотря на почти макроассемблерный стиль компиляции и отсутствие развитой оптимизации, ТР порождал более быстрые и компактные программы, если смотерть на что-то средних размеров, а не на отдельные функции. При этом совместимость с ТР оставляла желать лучшего, собрать что-то большое на SB было уже нельзя. Тем не менее, я применял SB и как раз для embedded.

MZ> Хотя сама идея, залеплять в исходники управление компилятором мне не MZ> нравится. Как тогда быть с повторным юзаньем кода и переносимостью MZ> на другие платформы?

Пренос на другие платформы - вопрос реализации для этих платформ тех же идей. А какие проблемы с повторным использованием кода-то?

MZ>>> При этом под каждую версию паскаля надо иметь либо исходники и MZ>>> строить либы самому либо иметь кучу либов. Потом есть у тебя некий DO>> Это недостаток реализации, а не концепции. Впрочем к сторонним DO>> либам без исходников у меня изначально настороженное отношение. MZ> А у меня к турбине, особенно после взгляда на исходники компилятора.

Ну это не исходники, а реверс-инжиниринг, да и там на ассемблере практически все.

MZ>>> TPU, а к нему документация должна быть. У си есть инклуд, кторый MZ>>> наврядли забыли поправить. DO>> У ТР есть .int файл в котором интерфейсная часть модуля DO>> описывается. MZ> Он сам генерился? я просто уже не помню.

Нет, он генерился путем копирования в редакторе от начала файла до слова implementation. Вот в SB он таки сам генерировался.

MZ>>> IAR-овская IDE кстати далеко не фонтан. MZ>>> Существенно хуже была наверно только у ваткома :) MZ>>> Применительно к эхотагу uVision3 от кейла несравнимо приятней.

DO>> Я вообще стараюсь постепенно разобраться в управлении компилятором DO>> и линкером и перейти к make-файлам, запускаемым из привычной мне DO>> оболочки.

MZ> если компилято в виде экзешника, то это делается просто. MZ> вместо компилятора подсовывается экзешник, который шлепает в файл MZ> переданые параметры а потом запускает компилятор. MZ> Делаем построение в оболочке и имеем дамп параметров.

MZ> но тут есть грабля, если выйдет новая версия компилятора с MZ> оболочкой, то где гарантия что парамеры командной строки не MZ> изменятся?

Никакой гарантии, как и никакой гарантии, что не изменится формат конфигурационны фалов IDE и набор опций в самой среде.

DT>>>> вставляю "интерфейсную секцию", вроде паскалевской, а потом DT>>>> специальной приблудой выделяю её в h-файл. MZ>>> А зачем? H файл не часто меняется.

DO>> Смотря на каком этапе проекта.

MZ> Hа начальном открой два файла да редактируй оба, в чем проблема то?

В ручной работе, череватой неприятными ошибками.

MZ> А ежели оболочка не может дерево проекта показать, то нафиг она MZ> такая нужна?

Привычка.

dima

Вот полностью поддерживаю. Особенно на счёт библиотек и языков. Нет общеупотребимых программных интерфейсов (ВСЁ ДЕЛО В ИНТЕРФЕЙСАХ!) -- однозначно идёт в сад. Это не столько даже на уровне возможности компоновки с C/C++ библиотеками. Это и генераторы интерфейсов к другим языкам, готовые реализации, для данного языка, ряда общеупотребимых интерфейсов от GUI до Corba и XML-RPC.

В паскале с этим традиционно было плохо. Да были какие-то свои библиотеки, полные разных багофичей и не поддерживаемые. Вот и всё.

В паскале интерфейсная часть от исходника вполне может отрываться. Вот уж не помню как и зачем. Помню мучался, писал на паскале парсер паскаля же для отрывания этого интерфейса от исходника...

Приятней чем? Как редактор я его даже рассматривать не стал. Побуждает разбить монитор. Мышью увозишься. В плане отладки предусматривает кое-какие интересные возможности конечно. Но попытки использования встроенного язычка недо-C быстро заводят в тупик (ну взяли бы хоть тот же TCL, тот же Python...) А остальное как-то, несмотря на все плюсы, перекрылось убогонькой штатной IDE в комплекте Cygnal'овского контроллера. Биты в регистрах позволяет разглядывать, таблицу символов от того же Keil'а подхватывает -- и ладно.

Тут вопрос между двух крайностей. Или, как для Java рекомендуется, каждая мелочь реализуется в отдельном файле, и, тогда, без специальной IDE в этой куче файлов никак не разобраться. Или весь исходник упихивается в один большой файл (а что, так оптимизация лучше!) -- но тогда тоже для навигации по файлу нужна специализированная IDE. Истина, возможно, где-то посередине.

Для языка C, на самом то деле, критерием того, что должно размещаться в отдельном файле является видимость символов в пределах пространства имён модуля (объектного файла).

lisp и его производные, вроде scheme. С последнего есть трансляторы в C (chicken).

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

Они бывают разные. Вот libc твоего C-компилятора -- она с исходниками? А бывает, что и без. А никак её не выкинешь. Хотя в целом, согласен, тащить всякую дрянь, необдуманно, да и ещё без исходников, чревато.

Удивительно, что никто не додумался до реализации такой элементарной вещи, как вставка include в исходник прямо в редакторе. Т.е. в окне редактора. Строки от такой-то до такой-то принадлежат одному файлу, от такой-то до такой-то другому... Хотелось бы, чтоб по-быстей появилось в Vim...

Вменяемые IDE умеют генерацию Makefile и последующий запуск make.

Или, что не изменится расположение галочек в окошках. Нужна формальная запись всех опций. Makefile таковой является, пусть и несколько невнятно. Галочки в окошках -- нет (их распечатать нельзя, на бумагу, скриншоты не предлагать).

А какая может? Я деревья какие-то там в source navigator видел. Впечатляет, но толку не много. Для ковыряния в чужих исходниках -- да, полезно. В своих и так более-менее понятно.

Ещё cscope попадалось. Занятная программка. А для построения исключительно дерева и cflow достаточно.