Embedded OS

Hi Olga!

07 Apr 05 23:03, Olga Nonova wrote to Slav Matveev:

SM>> #define BEGIN { SM>> #define END }

ON> Предлагаете с помощью макросов препроцессора переделать язык Си в язык ON> Pаscal? я предлагаю перестать заниматься интеллектуальный онанизмом и не придумывать проблемы там где их нет. ON> Во-первых, не получится из-за ублюдочности макросов в Си. ON> Во-вторых, не проще ли сразу написать нормальные макросы для ON> макроассемблера, минуя Си вообще? "только бодрый онанизм укрепляет мышцы рук." ON> В-третьих, дело совсем не в том, как можно макросами исправить ON> плохой синтаксис, а в другом- разработчики языка Си создавали язык ON> для торопливых и неаккуратных людей. Одно это уже ставит крест на ON> данном "произведении". читая ваш бред хочется процитировать удаффком: "афтар, убей себя", ибо сколько идиотизма относительно Си я в этой эхе прочитал за последние две-три недели, я не слышал за предыдущие 20 лет. Один мой коллега, ознакомившись и с паскалем и с си, выдал хорошее резюме: "паскаль - это встал на рельсы и погнал никуда не сворачивая, а си... вышел в чистое поле и п©©дуй куда хочешь". Я думаю что это исчерпывающе характеризует оба языка. Если вы не умеете ходить иначе как строем и в чистом поле обязательно вляпаетесь в коровью лепешку, Си не для вас. что вы с изрядным упорством и демонстрируете.

Slav.

Hello Vladimir.

08 Apr 05 00:39, you wrote to Nickita A Startcev:

NAS>> ошибок/предупреждений компилится как си, но не компилится как NAS>> с++.

VV> Всегда пожалуйста. VV> //------ Foo.c --------- VV> #include <stdio.h>

VV> void Foo(void) VV> { VV> printf("\n Foo"); VV> } VV> //------- Main.cpp (Or Main.c) -------- VV> #include "foo.h" VV> void main(void) VV> { VV> Foo(); VV> }

Ты не привел 'foo.h', а от него то как раз все и зависит. Причем, то, что ты привел скомпилируется, но не слинкуется.

ps: Hо да. Когда я переименовывал свой Main.c в Main.cpp кроме проблем с хидерами попадались и другие места, на которых c++ выдавал ошибку. Сейчас не вспомню, я их просто подправил и забыл.

Alexey

Hello everybody.

07 Apr 05 14:34, George Shepelev wrote to Olga Nonova:

ON>> смысле. Зато, когда не торопясь набираешь BEGIN, то успевашь уже ON>> твердо осознать, где будет располжен END и что из этого последует ON>> по смыслу. GS> Hикто не мешает пользоваться редактором, который нехитрой комбинацией GS> клавиш вставляет готовый пустой блок begin/end ;)

Я пять лет писал на паскале, теперь пять лет пишу на Си. Гон все это. Разница паскаля и Си не в скобках.

Alexey

Hello George.

07 Apr 05 14:35, you wrote to Alexander Golov:

AG>> следует использовать слово "присвоить" ("assign", или ещё AG>> какой-то синоним). GS> Сделай макрос, чтобы можно было набирать assign вместо mov ;-)

Лучше сокращенно, ass ;)

Alexey

*** Ответ на письмо из carbonArea (carbonArea).

Привет, Vladimir !

08 Apr 05 , 01:39 Vladimir Vassilevsky писал к Nickita A Startcev:

NAS>> Интересно было бы глянуть на текст, который без NAS>> ошибок/предупреждений компилится как си, но не компилится как NAS>> с++.

VV> Всегда пожалуйста.

VV> //------ Foo.c ---------

VV> #include <stdio.h>

VV> void Foo(void) VV> { VV> printf("\n Foo"); VV> }

VV> //------- Main.cpp (Or Main.c) --------

VV> #include "foo.h"

VV> void main(void) VV> { VV> Foo(); VV> }

g++ main.c:4: `main' must return `int' main.c:4: return type for `main' changed to `int'

gcc main.c:4: warning: return type of `main' is not `int'

Оно?

После исправления с void на int всё собралось и заработало без предупреждений. . С уважением, Hикита. ... в начале был кофе ?

Alexander, ты ещё здесь сидишь?

Четверг Апрель 07 2005 06:12, Alexander Aleshenko wrote to George Shepelev:

GS>> И ты будешь в восторге, если любая <beep> будет настойчиво GS>> обращаться к тебе исключительно "Шура", "Шурик" и т.п., правда? AA> Георгий, я к этому отношусь с иной позиции, если меня в коллективе AA> называют Шурой - значит я уже в коллективе свой человек,

Коллектив из дюжины людей, которые каждый день друг-дружку видят и коллектив всемирной сети - несколько разные вещи, не так ли?

AA> а поскольку в коллективе люди разные, есть и такие которые мне не AA> нравяться или как ты их называешь <beep> я не требую от них, чтоб они AA> называли меня официозно - это бессмыслено.

Тем не менее в Policy есть высказывание насчёт перехода раздражающего поведения в чрезмерно некорректное (1.3.5). И когда модератор эхи следит, чтобы такого перехода не происходило - атмосфера в эхе _гораздо_ приятнее для участников...

Георгий

Olga, ты ещё здесь сидишь?

Четверг Апрель 07 2005 22:03, Olga Nonova wrote to Slav Matveev:

SM>> добавить в stdio.h две конструкции для препроцессора SM>> #define BEGIN { SM>> #define END } ON> Предлагаете с помощью макросов препроцессора переделать язык Си в язык ON> Pаscal? Во-первых, не получится из-за ублюдочности макросов в Си.

Препроцессор - вообще отдельная от C сущность... Ублюдочная ;)

Георгий

Привет Sergey!

Friday April 08 2005 10:58, Sergey Mudry wrote to Alexander Torres:

AT>> Си на спектруме не пробовал - AT>> сам компилятор у меня был, без *.h-файлов, а когда они появились - AT>> это уже было неактуально. SM>

SM> Я пробовал. Hisoft C. Hе понравилось. Занимает больше памяти, чем тот же

Именно он у меня и был, без .h

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

, ftp://altor.sytes.net

Hello, Alexander! You wrote to Andrey Solomatov on Thu, 07 Apr 2005 19:55:00 +0400:

AT> Си на спектруме не пробовал - AT> сам компилятор у меня был, без *.h-файлов, а когда они появились - это AT> уже было неактуально. Я пробовал. Hisoft C. Не понравилось. Занимает больше памяти, чем тот же паскаль, но плавучки нет, прототипов функций нет, некоторые фичи в языке нестандартные, например, для приведения типа вместо (char)x надо было писать что-то типа cast(char,x). Зато умел работать с кассетными файлами, при работе с fprintf писал на кассету блоками по 512 байт с двухсекундными паузами, в таком же виде сохранял исходники и умел компилировать их на лету прямо с ленты :))) А h-файлами я и не пользовался, всякие мелкие функции типа printf, strcpy там уже были вшиты, отдельно шёл аналог stdlib.

With best regards, Serg.

Hello Harry.

08 Apr 05 13:19, you wrote to Nickita A Startcev:

HZ> что делает enum'ы в С совершенно бесполезными и HZ> ненужными.

Почему?

Alexey

Hello, Olga Nonova !

А тут не о чем спорить, вменяемых реализаций Паскаля для embedded просто нет и не предвидится. Иногда есть выбор С или С++, часто нет и его, только С. Потому ваша забота выглядит просто флудом, таким же бессмысленным флудом, который обычно исторгает Жора, тоже обожающий трепаться о том, чего он не знает или о том, чего вообще не существует в природе.

С уважением, Дима Орлов.

Привет George!

Чет Апp 07 2005 15:29, George Shepelev пишет Alexey Boyko:

GS>>> задачки "детские"? AB>> Отстань. Это уже было.

GS> Т.е. для _твоих_ задачек 16-ти РОH хватает. Я рад за тебя. Hо зачем GS> было делать настолько корявую архитектуру - всё равно непонятно...

А если вместо 16-и стаpших РОHов будет ОДИH камулятоp - это менее коpяво ? Тогда Юзай 8051 клоны ... Посмотpи двоичный фоpмат АВРовских команд тогда всё станет на свои места - пpосто не хватает pазpядной сетки -ил делать на паpу бит больше ?

С наилучшими пожеланиями Nick .

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

Fri Apr 08 2005 10:41, Slav Matveev wrote to Olga Nonova:

ON>> ... разработчики языка Си создавали язык ON>> для торопливых и неаккуратных людей. Одно это уже ставит крест на ON>> данном "произведении".

SM> ....сколько идиотизма относительно Си я в этой эхе прочитал SM> за последние две-три недели, я не слышал за предыдущие SM> 20 лет.

Отчасти, такова моя задача- оказать отпор агрессии языка Cи. За счет разрушения мифов о его якобы удобности, портируемости и вседозволенности дать пищу юношам, только вступающим на скользкий путь ембеда. И у меня еще есть, что сказать. Hапример, про неаккуратный вид Си-листингов. Присмотритесь к печатному листу в целом,- обилие фигурных скобочек создает полную иллюзию измятой и использованной в клозете бумаги.

SM> Один мой коллега, ознакомившись и с паскалем и с си, выдал хорошее SM> резюме: "паскаль - это встал на рельсы и погнал никуда не сворачивая, SM> а си... вышел в чистое поле и п©©дуй куда хочешь". SM> Я думаю что это исчерпывающе характеризует оба языка.

Вполне возможно. Однако, в представленной характеристике чувствуется вполне разумное неодобрение сишной манеры.

SM> Если вы не умеете ходить иначе как строем и в чистом поле обязательно SM> вляпаетесь в коровью лепешку, Си не для вас. что вы с изрядным SM> упорством и демонстрируете.

С опытом практической деятельности начинаешь понимать, что результат быстрее и надежнее достигается именно маршируя "строем" по многократно проверенным путям. Я совершенно согласна с предыдущим оратором, что программирование на Си- это бессмысленное метание мухи в бутылке в поисках выхода, нечто в роде Монте-Карло. Зато пчела-паскалистка сразу поползет к выходу из бутылки и обретет свободу много раньше мухи. Это к вопросу о скорости достижения практического результата.

Всего Вам Хорошего Ольга

PS. Во многих фидоэхах спор C vs Pascal обьявлен офтопиком навечно. Поскольку были уже случаи нешуточных физических травм с обеих сторон.

Thu, 07 Apr 2005 00:32:06 +0400 Nickita A Startcev wrote to Harry Zhurov:

HZ>> Hе каждый С текст компилится в С++. Есть несколько нюансов.

NA> Интересно было бы глянуть на текст, который без ошибок/предупреждений NA> компилится как си, но не компилится как с++.

Пожалуйста:

// ------------------------------------------------------------------ typedef enum { slon, slonick, mamont } TSlon;

TSlon Slon;

int main() { Slon += 1; } // ------------------------------------------------------------------

В С++ арифметика с перечислимыми типами запрещена равно, как и присвоения объектам перечислимого типа целых. В С это можено делать совершенно свободно, что делает enum'ы в С совершенно бесполезными и ненужными.

Можно и еще привести примеры, но лучше об этом в книжках почитать.

Thu, 07 Apr 2005 19:35:46 +0400 Alex Mogilnikov wrote to Harry Zhurov:

HZ>>>> А прямое обращение к памяти - это прямое обращение к памяти. Или HZ>>>> ты не знаешь как это делается?

AS>>> Hет, не знаю. Расскажи.

HZ>> Стебаешься? Или правда не знаешь?

AM> Я вот тоже не знаю, что ты имеешь в виду. Есть разные способы адресации AM> - непосредственная, прямая, косвенная, индексированная, AM> индексированно-косвенная, косвенно-индексированная (сразу 6502 вспоминается AM> :) ) и т.п.

Ты перечислил способы аппаратной адресации, к языку это не имеет отношения.

AM> Все они в конечном итоге адресуют данные в памяти. И использование AM> переменной - это всегда доступ к памяти.

Это можно сказать про любой язык. Попробуй обратиться на языке AWK к переменной по адресу 0x000A.

AM> Так что такое особенное есть в языке C и прямом методе адресации при AM> обращении к памяти?

Особенного то, что это можно сделать. А в паскале можно (в паскале, а не в его диалектах и расширениях типа делфы)? К ячейке памяти по физическому адресу.

AM> Или ты говоришь о том, что тип указателя может быть преобразован к AM> целому?

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

Hi Olga!

08 Apr 05 13:57, Olga Nonova wrote to Slav Matveev:

SM>> за последние две-три недели, я не слышал за предыдущие SM>> 20 лет.

ON> Отчасти, такова моя задача- оказать отпор агрессии языка Cи. За счет ON> разрушения мифов о его якобы удобности, портируемости и ON> вседозволенности дать пищу юношам, только вступающим на скользкий путь ON> ембеда. О как, да вы мессия! Тогда вам лучше к психиатору. ON> И у меня еще есть, что сказать. Hапример, про неаккуратный вид ON> Си-листингов. Присмотритесь к печатному листу в целом,- обилие ON> фигурных скобочек создает полную иллюзию измятой и использованной в ON> клозете бумаги. Точно. К такими аллегориями только к психиатору. И как можно скорее.

SM>> не сворачивая, а си... вышел в чистое поле и п©©дуй куда SM>> хочешь". Я думаю что это исчерпывающе характеризует оба языка.

ON> Вполне возможно. Однако, в представленной характеристике чувствуется ON> вполне разумное неодобрение сишной манеры. Восхищение.

SM>> Если вы не умеете ходить иначе как строем и в чистом поле SM>> обязательно вляпаетесь в коровью лепешку, Си не для вас. что SM>> вы с изрядным упорством и демонстрируете.

ON> С опытом практической деятельности начинаешь понимать, что результат ON> быстрее и надежнее достигается именно маршируя "строем" по многократно ON> проверенным путям. строем ходит биомасса. творческие люди строем ходить не умеют. подумайте над этой особенностью на досуге. Я думаю что после посещения психиатора у вас будет много времени для этого. :)

ON> PS. Во многих фидоэхах спор C vs Pascal обьявлен офтопиком навечно. ON> Поскольку были уже случаи нешуточных физических травм с обеих сторон.

И что характерно. Кто на этот раз начал боевые действия?

Slav.

Hello, Andrey Solomatov !

Мне было легче, когда довольно большие не завязанные непосредственно на железо куски программ компилировались без каких-то изменений и для х86 и для восьмиразрядных embedded платформ. Паскаль (турбо) нормально даже с DOS на Win не перетаскивается. И не потому что это какое-то органически присущее паскалю свойство, нет, просто нормой писания на нем всегда было хакерство. Тут ассембленрная вставка, там натягивание несовместимых типов etc, etc. Отчасти это было связано с крайне низким качеством турбопаскалевского кодогенератора. Причем в этом стиле написано все, все популярные библиотеки, все примеры.

Железонезависимые куски - вполне.

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

С уважением, Дима Орлов.

Fri Apr 08 2005 17:54, Harry Zhurov wrote to Alexey Boyko:

HZ>>> что делает enum'ы в С совершенно бесполезными и HZ>>> ненужными.

AB>> Почему?

HZ> Я ж объяснил вроде. :) Hу хорошо, ответь тогда, зачем в С такой HZ> перечислимый тип, при использовании которого все работает ровно так, как HZ> будто это просто целое?

Меньше писать, понятнее программа. Hесколько ограничена область видимости.

HZ> Чем это лучше того же использования просто HZ> макросов (#define)?

См. выше.

HZ> Скажешь, что HZ> при его использовании можно, типа, не озабочиваться указанием значений?

И это тоже.

HZ> Да, это так, но это такая мелочь, что из-за нее не стоило бы вводить в HZ> язык эту конструкцию.

Hикто ведь не заставляет ей пользоваться.

WBR, Yuriy.

Привет, *Harry*!

/четверг, 07 апреля 2005/ *Harry Zhurov* писал(а) к *Andrey Solomatov* по поводу *Текстовые строки (было: Embedded OS):*

[кусь]

HZ> Нет, С++ рождался не на пустом месте, как и почти любой ЯП. HZ> Конкретно, С++ рождался на основе С и Симулы.

С некоторой оглядкой на Алгол, как уверяет Страуструп.

AS>> Да и мало он был распространён на момент стандартизации.

HZ> Стандартизации чего? С? Или С++?

C++ - на момент стандартизации C. И интенсивно развивался (С++). А говорить о "развитии в сторону" чего-то, быстро изменяющегося - несколько некорректно, имхо. Ну а "в сторону приближения" - всё-таки более корректно. Тем более, что это не исключает одновременного приближения и к алголу, и к остальным подобным. ;)

[кусь]

HZ> Тогда надо было писать K&R.

А... Действительно глюкнул. Почему-то мне помнилось именно C&R.

[кусь]

HZ> Это смотря по какому изданию. По 2-му там такого уже нет, уже ANSI HZ> вовсю рулит.

Угу. Но обычно когда упоминают K&R - говорят именно про "старый стиль".

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

Ну, в таком случае пресловутая "стандартизация C" - это от безысходности. В результате C достиг уровня стандартности паскаля, и только. ;))

[кусь] HZ>>> А прямое обращение к памяти - это прямое обращение к памяти. Или ты не HZ>>> знаешь как это делается?

AS>> Нет, не знаю. Расскажи.

HZ> Стебаешься? Или правда не знаешь?

Блн. Третье писмо пишу - не знаю. Точнее - не понимаю, о чём ты говоришь.

[кусь]

HZ> Это потому, что ты на паскале писал. И на РС. А когда на МК HZ> подсядешь, так сразу поймешь, в чем "сермяжная правда жизни". :)

Возможно. Но, тем не менее, никак не могу придумать ситуацию, когда может понадобиться инкрементация именно указателя - а не индекса.

[кусь]

AS>> Ты всерьёз хочешь меня уверить, что в C++ легко "выйти за границы"?

HZ> "Как два байта переслать" (с)! С++ никого насильно не держит - HZ> хочешь нарушить контроль типов - нарушай (через явное преобразование), HZ> прога скомпилится без проблем.

Ну так это - _явное_преобразование_. Т.е. ты прямо сказал компилятору "делай так". И, кстати, даже это срабатывает не всегда - иногда компилятор упирается.

[кусь]

AS>> Не люблю typedef.

HZ> ? А он не девушка, чтоб его любить.

А дэвушек я люблю. ;)

HZ> Он есть средство для достижения определенной цели. Вполне удобное. И не HZ> пользоваться им к месту просто, мягко говоря, неразумно.

typedef не удобен. Потому, что разрывается общее определение того, что это есть: "typedef struct" и само имя типа. Между ними может быть весьма много текста.

AS>> Лишняя прибамбасина,

HZ> Очень полезная "прибамбасина", позволяет вводить удобные синонимы HZ> для типов.

Если бы он вводил разные типы - цены ему бы не было!

[кусь]

HZ> Это ты не тип определил, а объект объявил. Нету тут типа. А если HZ> написать:

Да, я вспомнил. Это уже общие особенности синтаксиса C. ;))

HZ> typedef struct TAbc HZ> { HZ> // HZ> // Здесь дли-иинное определение структуры HZ> // HZ> } TAbc;

"Верхний" TAbc - лишний, а нижний - оторван от определения typedef. Что не есть хорошо для читабельности программы.

[кусь]

AS>> Ну его, C++ лучшее. ;))

HZ> Да, в С++ лучше, но это _мелочи_.

Ну, когда соберается много мелочей - получается крупная хорошесть. ;)

[кусь]

HZ> Причем тут перегрузка? Вопрос был про С программы. Откуда там HZ> перегрузка?

А, я спутал. "Что из-под C++ не скомпилируется правильно под C".

[кусь]

HZ> Ниче не понял! Что такое "набор get"?

get(char); get(int); get(long); get(char*); ...

[кусь]

HZ> Вот я и спросил, на какую платформу в ембеддах ты перешел?

Инфинеон C167

[кусь]

HZ> Ерунда какая-то. Под какую платформу? Какой компилятор?

Tasking C166/ST10 v.7.5