for (f = 0; f < 2; ) { ... } if (strtol(buf, &z, 16) == x && printf("%s, buf)) break; Ы? (hint: printf возвращает кол-во символов, выведенных в поток, если первое условие истинно, то printf вернет > 0) p.s. brainfucker
Виноват, перепечатывал на скорую руку. Для меня это не хак и не трюк (я понимаю, как это работает), а образец плохого стиля.
На момент рождения C уже существовали, как минимум: алгол - прямой предок паскаля, фортран, бейсик Это из того, что я вспомнил из того что дожило из того, что похоже. Кроме того разнообразных макроассемблеров было может и поболе чем счас. Кроме того с тех пор родилось и умерло только потомков алгола/паскаля (ну скажем живут, но в узких кругах), несовместимых между собой, а С развивается дальше. Язык С зародился путем добавления типов в любимый толи керниганом, толи ритчи интерпретируемый язык B (судя по всему, что-то типа жаба-скрипта) еще в их студенческие годы. Впоследствии это все переписалось как компилятор и, названо С. Впоследствии при написании юниха, тоже любительским полуподпольным методом, который то принимали, то отправляли на доработку, юних был переписан для простоты дорабатывания на любимом "своём" С и оформлено все это в виде отдельных мелких утилит, а С в тех-же целях в виде кучи отдельных библиотек. Впоследствии свои проекты С-юнихо-предки старались если можно выполнять на так до конца и не принятом С-юнихе причем система с компилером предоставлялась в довесок, как необходимая библиотека. Бесплатная система понравилась универам. Простота и заточеность на простоту доработок облегчили портирование. Профессора со студентами понапереписывали с фортрана библиотек - глупо не юзать халявную систему с компилером, заодно и поправили их. Вообще-то странно слышать о С как о макроасме на форуме асмовцев. Мне довелось пописать может не на самых первых но еще KR версиях С и на ранних версиях Паскаля. При этом паскаль выглядел как сильно урезаное С с измененным синтаксисом. То-есть паскалевский исходник можно было перевести в С простой заменой оператор -> оператор. Ну тут все напрямую завит от опыта. Некоторым и анекдоты про ржевского надо по десять раз рассказывать. В случае полных потемок - спим, достаем бумажку и дебугер.. Кстати про С++ я ничего и не говорил - перемудрили там малость или похмелиться забыли. Хотелось-бы увидеть компилируемый без ошибок и предупреждений пример, где бы алгоритм серьезно менялся скажем, на openwatcom (с99) и на gcc (gnu c). Более того, разные результаты можно получить и на одном компилере, но при разных оптимизациях. От ошибок не застрахован никто. Иногда найденые юзерами ошибки выставляются как корпоративная политика некоторыми гоноровитыми компаниями. Tолько причем тут С?
BreakPointMAN > Для меня это не хак и не трюк (я понимаю, как это работает), > а образец плохого стиля. видишь ли, когда ты выступаешь как работодатель/заказчик или просто ищещь ppl в тим, то твои претензии к стилю вполне обоснованы. тоже относится к ситуации, когда ты берешь чужую open-source программу и думаешь - юзать ее или нафиг-нафиг... во всех остальных случаях... не, ну ты, конечно, можешь мне посоветовать избегать таких конструкций, потому что они уменьшают мои шансы найти работу в силу перечисленных обстоятельств. только ведь я это и так знаю и ты знаешь, что я это знаю и ты не работодетаель, и я не озабочен поиском работы до такой степени, чтобы демонстрировать "хороший стиль" везде, где это возможно... я пишу так... примерно так же, как и говорю... то есть, при _беглом_ кодировании программирую в стиле потока сознания... точно как и при беглом письме... ес-но, при вдумчивом кодировании поток мыслей приходится структурировать так, чтобы не получился листинг в стиле write-only образцами кода с хорошим стилем размахивать не буду, поскольку, он определяется руководителем тима... ну вот, например, одни предпочитают короткие переменные в стиле x[n] = y[m], другие же требуют длинные переменные да еще и в венской нотации, которые по моему глубокому убеждению ухудшают читаемость кода, строки выходят длинными, их приходится разбивать, заморачиваясь с форматированием и все это жутко ненаглядно... но каждому свое.
2 _basmp_: О чем мы спорим, дружище? -) Программа должна быть как песня, доставлять моральное и эстетическое удовлетворение ! А в реале имеем жестокий гемор с разбором маловразумительных конструкций и грязных хаков. :-((( Который еще и работает у всех по разному - у кого какая среда разработки/версия компилера. :-( Попытка свернуть в дебри стандартов языка С/С++? Тема конечно интересная, но... Стоит ли на это тратить свое время и свои силы ? А вот это истинное лицо Зла !!! Это же крутая оптимизация получается, что она влияет на результат вычисления, не так ли ? Получается предсказать работу алгоритма становится практически нереально- вдруг девелопер включит какой-нибудь вариант оптимизации. Еще раз уточним: оптимизация кода ни в коем разе не должна лезть в логику алгоритма. Попробуй оптимизировать проект на Дельфах. Ну размер кода изменится, скорость отработки отдельных процедур. Но числовые результаты теста будут одинаковыми, несмотря на разные ключи оптимизации.
4apa Должна. Но только в двух случаях: а) если алгоритм откровенно уродский (пузырьковая сортировка, например) -- здесь оптимизация на уровне именно алгоритма (а точнее, замена его на более эффективный); б) если по каким-то причинам надо выжать всё возможное любой ценой. Первый случай встречается не так уж и редко, но говорит лишь о недостаточной квалификации программиста. Второй -- очень редко.
BreakPointMAN Да-да. Только цепляясь к неудачным примерам написанным на C, ты зря переводишь стрелки на язык. C, как ЯВУ, позволяет писать весьма читабельный код. Я ни на каком другом языке не видел кода читабельнее чем сорцы линуха (может всё из-за "тут все напрямую завит от опыта" (c)_basmp_, я не спорю). А линух, ведь, это С, с парочкой дополнений от gcc, которые перечислены в CodingStyle. Правда и самый уродский код, который я ковырял, тоже был написан на C.
2 SII: И все таки, позвольте не согласиться с Вами, уважаемый SII. Вы пытаетесь смешивать разные понятия: "оптимизация алгоритма" и "оптимизация кода". Если против "оптимизации кода" я в принципе не возражаю (т.к. на мой алгоритм никто не покушается), то в отношении к самопальной (автоматизированной) оптимизация алгоритма- я жестоко и категорически возражовываю! Если я пишу алгоритм типа (а) (неэффективный алго), значит у меня так и задумано. Может мне надо прогрузить камень интенсивными вычислениями, а ? Если имеет место случай п. (б)- тогда нефик доверять оптимизацию автоматике, алгоритм пишем с учетом кокретной аппаратной/программной архитектуры ЭВМ. Вроде бы так, еслив ничего не напутал -).
Код может быть читабельный, понятный, но неэффективный - пример "Прямая реализация подсчета CRC". Код может быть читабельный (хотя как сказать), с первого раза непонятный, но эффективный - пример "Реализация подсчета CRC табличным способом". Код может быть плохо читабельный, непонятный без детального разбора, но эффективный - пример "Зеркальный" табличный алгоритм. В коде всегда встречаются ошибки, как критические так и не совсем, если об этом забывать, то конечно можно налабать весьма "крутой" код, но цена ошибки в таком коде будет очень высокой. Потому, я всегда с уважением относился к тем программистам, чей код ясно отражает поставленную задачу перед ним, не имеет сокращений и макросов понятных только автору кода, и к сожалению такой код большая редкость. Сейчас ресеч и обдумывание кода составляет 70-80% времени написания, на сам код трачу 10% времени и еще 20% на тестирование, причем тестирование закладывается сразу в код а не потом.
Прога любом языке програмирования - это компромис между человеческими и машинными способами представления информации. Таким образом это песня, но чукотская и на монгольском языке. Вы книжки читаете? Вам все нравится? Если что-то не нравится предложите свой лучший вариант, авось все за вами пойдут. Такие утверждения необходимо аргументировать, утверждение подобного рода без обоснований - просто безграмотный треп. Единствено чем может похвалиться дельфи в этой связи - отсутствием альтернатив. Вот и нет вопроса с переносом. Вы утрируете. Компилерная оптимизация не лезет в логику алгоритма тк не знает о ней. Есть ошибки, которые иногда легче принять как внутрений стандарт, чем раскошеливаться на претензии пользователей. Выход - не пользоваться закрытыми коммерческими компилерами, а возникающие ошибки править в исходниках открытых компилеров. И себе и другим поможете и скепсису поубавится и опыту аж зашкалит. В свое время отказался от делфи как от системы рад разработки именно из-за редких но очень странных ошибок, которые часто удавалось починить скажем так a:=a; в месте ошибки, причем а - общая переменная (Integer) и используется в ф-ции и до и после. Оптимизация есть всегда - проц плохо понимает конструкции типа FOR i:=1 TO 100 DO BEGIN ... END. Значение имеют ее приоритеты. Для получения точного кода лучше всего его записать цифрами (маш код), тк х86 асм мнемоники можно переводить в код по разному. Кстати говоря относительно оптимизации - взляните на опции openwatcom-а. Их много, они хорошо описаны и предоставляют много очень полезных возможностей. Относительно опенваткома два момента: 1) Как полностью убрать дебуговую инфу из exe не правя линкер? 2) Знаете ли вы, что в ваткомовских сорцах есть полезные инструменты которых нет в бинарнике - так там есть преобразователь С .h в асм .inc (wic), причем переводит практически все. 4apa Насколько я понял вы паскальщик. Хотелось бы узнать ваше развернутое мнение о современных паскалеобразных рад системах (оберон, блэкбокс) по следующим моментам: - Глючность кода. - Простота языка и удобство програмления. - Возможность перевода результата в обычный ехе без дополнительных длл-ей. - размер/быстродействие полученого ехе-шника. - отлаживаемость. - развитость инструментов (блэкбокс и скажем нативный виртовский оберон http://www.oberon.ethz.ch ) - встроеный асм и возможность непосредственного задания маш кода.
Именно поэтому я не могу много трепать на форуме, забанят и на звание не посмотрят ))) (просто когда то я наговорил много лишнего, и поэтому мне в назидание прицепили это погоняло, чтобы я поменьше висел на васме). обидно канешно, но сказать против никто ничего не может. :-(
4apa И все-же возвращаясь к моему предыдущему вопросу, мне очень интересен был-бы продуманный (не треп) обзор (см. выше) и возможно я думаю не мне одному ибо потенциал там немеряный, жаль, что паскаль в основе. Авось за созидательное участие в работе сайта (обзорную статью) вам простят грехи молодости. ЗЫ кстати там есть еще и основанная на обероне ос BlueBottle, о ней тоже неплохо-бы черкнуть пару слов.
1. Единственное, что я могу Вам сказать, системы надежного программирования(Оберон, компонентный Паскаль и т.д.) стоят того, чтобы потратить время на их изучение. Пропагандировать их конечно можно и нужно, но... не на Васме -) А смысл, если любая новая информация на Васме воспринимается как необоснованный треп ? :-((( Если бы у меня была возможность проводить исследования в области Оберона, я б не отказался воспользоваться Вашим советом на счет статьи для Васма. А сейчас я увы, не располагаю даже такими минимальными средствами. Поверьте, что веселого в этом мало.... 2. Мне не нужно прощать какие либо грехи молодости, пусть администрация себе прощает свои грехи. Или они тут работают за безгрешных ангелов? ))) З.Ы. Вот вам ресурс по Оберону, читать надеюсь еще не разучились http://www.oberoncore.ru/ http://oberoncore.ru/download/articles/oberontech.pdf (Там все кратенько и на русском)
А как вы думаете, почему я вас спросил? Насколько я помню в обероне отошли от прицела на надежность свойственому ада и модула. В обероне и его потомках прицел взят именно на легкую масштабируемость. К примеру объектная модель оберана имхо самая удачная, кроме того сократили количество необходимых операторов, к сожалению не их длину, и вообще значительно улучшена читаемость, упрощено документирование, навигация по модулям. Кроме того в оберонах есть встроеный асм и возвожно использование С-шного кода, библиотек Почему? В реализациях оберона (их довольно много, блэкбокс только одна из них) есть встроеный АСМ, ядро написано именно на нем. А вы обосновывайте. Кроме того оберон тут уместен не менее чем С. Если вы пишете в форум, то средства все-таки есть. Требования у оберон систем очень небольшие. 20-50Mb можно поверх другой системы (вынь/линух). пня первого вполне достаточно. или вы без восьми ядер на 20Ггц жить не можете? С начальством не спорят. Начальство право всегда. Знаете анекдот о том чему равно 2+2? Возможно поэтому у вас такое настроение? Вообще-то я то, что там я уже читал. Но это публицистика для школьников или студентов. Меня интересует более практический аспект. Насколько пригодны существующие оберон системы для использования в коммерческих проектах. Качество кода. Накладные расходы на модулирование. Возможность преобразования в другие форматы (exe, dll,..). Пригодность для написания драйверов, протекторов, вирусов, итд. Формат модулей. Опять-же отлаживаемость. См выше. Тут немало чего по тематике сайта, это только сверху оберон или С#. Такой обзор возможен только от паскаль/оберонщика/асмовца. Спецы только по ЯВУ, как правило, ничего не рубят в кишках своего инструмента. Кстати насчет почитать. Этого намного больше на Виртовском сайте (см выше), к примеру, кроме нескольких вариантов оберон систем с исходниками, там есть много описаний тонкостей реализации, описание встроеного асма, формат нескольких вариантов скомпиленых модулей. учебники, примеры... Но в это неплохо-бы разгрести. Испытать. Исследовать. И хотя-бы в кратце и в одном месте и с обоснованиями. С прицелом на низкий уровень. К примеру как обеспечивается надежность на уровне маш кода в модуле. Между модулями. Каков межмодульный интерфейс. Насколько гибок скомпиленый модуль? Скажем можно-ли подлинковать его к С проекту и как?
Ну как же Вы не можете понять то ???! (( У меня действительно нет возможности заниматься исследованиями... Ну стоит у меня дома три (ТРИ ШТУКИ) ПК. Ну и что ? Работать то я на них не могу... Скачал я вчера Голубую Бутылку. http://www.bbos.org/ethmirror/bluebottle.ethz.ch/downloads/crazy/AosCD.zip Первые впечатления (времени на тщательное изучение действительно не было): 1. Запускается прямо с СД-рома. 2. Пользовательский интерфес прикольный (необычный), но быстро привыкаешь. Чувствется продуманность и забота о программисте/операторе ПК (!!!). 3. Есть командная консоль, в которой прописаны алиасы на самые ходовые UNIX команды (cp, md, rd, список процессов и проч.). Можно своих алиасов навтыкать. 4. Есть удобный инсталлятор на винт! Запускается из консоли (или из стартовой кнопки): WMInstaller.Open ~ 5. Имеется куча программулин, от удобной разметки/форматирования/маунта диска и до всевозможных IDE-сред и мультимедиа-проигрывателей... 6. Вроде как никаких свап-дисков нигде не используется, есть стандартный RAM-диск.. 7. Внутренняя кухня Бутылки и Активного Оберона пока для меня остается загадкой, буду ковырять дальше..... Скриншоты и свежие загрузки: http://oberon.nnm.ru/ Размышления на тему: Бутылка без джинна (Oberon и нелетние мысли) (могла устареть, ибо от 17 июля 2002 г.) http://www.itc.ua/node/10552/
Устарело и лажа. Чел пишет, что мол нет ничего нового. Обероновская модульная система изобретена давно и есть всякие либы. На что можно возразить, что первую, а может и не первую самодвижущуюся повозку, работающую на паровой машине, сделал еще Герон Александрийский и она работала.
Согласен. Но тут есть пара интересных моментов. Этот товарищ рассуждает о новой технологии с точки зрения типичного обывателя, развращенного софт-поделками от мелкомягких. Причем этому обывателю хочется чего то такого высокого и необычного , чего он и сам понять не может. ) Главное, чтобы не надо было напрягаться или что нить изучать. Ну а с точки зрения программиста, получающего мощный инструмент выражения и реализации своих мыслей, Голубая Бутылка и Активный Оберон- конечно великое благо.
Я, все-таки, сакцентировал свое внимание на вин обероне и блэкбоксе в частности на их применимости в коммерческих проектах, в частности в составе С/С++ или многоязыкового проекта. И опять-же как вся эта модульная система работает и как обеспечивается надежность этой работы. Уж очень привлекателен тот-же блэкбокс для проектов на скорую руку, в 100 раз лучше делфи во всех отношениях. Но как получить на выходе один exe, dll или obj файл? Только с требуемыми функциями и интерфейсом? Как подлинковать к оберон/блэкбох проекту внешний obj или lib? Я думаю это будет очень интересно не только мне - с РАД системами работают все независимо от того, что они говорят про то-же Делфи.
