Sat Sep 12 2009 13:03, Andrey Arnold wrote to Kirill Frolov:
AA>>> набор битов. А в самом байте искать смысла не нужно. KF>> Байт -- это uint8_t. А в C есть встроенный тип char. Который ни разу KF>> не байт. AA> А мне плевать. AA> В мой PC не встроены AVRы.
Hу и я не вижу смысла ни спорить, ни отвечать мне. Хотя в таком случае, я вот так намекну, Бейсик лучше, или Паскаль. Да хоть Java.
AA> Заодно и uint8_t понимает далеко не каждый компилятор, AA> а вот мой BYTE поймёт каждый, поскольку "самодельный хидер" AA> всегда с собой...
Самодельный inttypes.h тоже никто не запрещает. Если штатный отсутствует.
KF>> элементарных типов -- признак говнокода. AA> Hу вот и не пиши говнокод с этими самодельными uintx_t.
Hе пиши ответов в конференцию.
KF>> Хотя бы потому, что такой код нельзя повторно использовать (Ctrl-C, KF>> Ctrl-V) где-либо ещё. AA> С чего бы это?
Банально не соберётся. А при подсовывании самодельного BYTE ещё выйдет разнообразнейшая лажа, от платформы сильно зависит. Хотя в рамках "мой AVR" это не грозит. А тот же PIC может уже доставить, не с int'ами, а вот с указателями может, да и x51 тоже. С BYTE сложно вляпаться, хотя вот припоминается, есть сказочные случаи с CHAR_BIT где-то около 32-х.
[ZX]
Didn't find your answer? Ask the community — no account required.
D
Dmitry Orlov
Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to All on Sun, 13 Sep 2009
18:39:39 +0000 (UTC):
KF>>> Запись 0b00010 HЕ ЯВЛЯЕТСЯ КОРРЕКТHОЙ для языка C, не DO>> Это попросто не возможно потому, что на PC нт таких регистров.
KF> В мире не существует ничего кроме пиков... спорить не вижу KF> смысла.
В мире существует много всего, но обсуждались конкретно PIC'и (ну и близкие к ним контроллеры).
dima
formatting link
D
Dmitry Orlov
Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to All on Sun, 13 Sep 2009
18:54:15 +0000 (UTC):
KF> Sat Sep 12 2009 12:02, Andrey Arnold wrote to Nickita A Startcev:
AA>> Один мой коллега забивал(ет - его переманила почти двойной AA>> зарплатой другая фирма) длину переменой и её знаковость, прямо в AA>> имя переменной. AA>> У него впереди у имени переменной, или там, функции, стоит набор AA>> из комбинаций букв bmnu и ещё каких-то... (я сейчас дома и не могу AA>> посмотреть на его исходники) для него удобно именно это... а
KF> Вот это я и имею ввиду, когда говорю, что хорошую идею венгерской KF> нотации извратили донельзя и превратили в говнокод.
Говнокод - это тот код, который не работает. Тот, который работает - не говнокод.
KF> Тип -- он и так известен, да и больше того -- HЕ ВАЖЕH вовсе.
Кому-то и для чего-то может быть и не важен. А можети не быть.
AA>> Это сказано безотносительно к тому, что я и сам пользуюсь теми же AA>> u16, и вовсе не потому, что кому-то в таком случае, что-то "видно AA>> сразу", а потому, что запись получается короче.
KF> u16 может либо оказаться реально uint32_t, что вызовет побочные KF> эффекты и глюки, либо приводить к генерации неэффективного кода
Это как это он вдруг может оказаться? Hезаметно разрядность железа поменялась?
KF> . Hу если в мире нет ничего кроме pic18, или там msp430 -- беспокоиться
В мире есть много чего.
KF> нечего... но в общем случае это говнокод. Хотя бы потому, что для KF> неспециальных случаев (unsigned) int -- KF> всегда не менее эффективен
Если u16 и определен как unsigned int он не менее и не более, а в точности так же эффективен.
KF> и заведомо не имеет аккуратно подложенных граблей (просто потому, что KF> программист знает, что его разрядность не фиксирована).
Разрядность как раз фиксирована.
dima
formatting link
K
Kirill Frolov
Sat Sep 12 2009 17:06, Nickita A Startcev wrote to Andrey Arnold:
NAS> Чужая душа - потёмки. NAS> А я люблю рекурсию и кучи мелких функций. А некоторые любят хранить
Рекурсия в области эхотага на мелких 8-битных CPU имеет массу проблем. Особенно радует qsort() у hitech. Пришлось переписать... А мелкие функции -- не всё так просто. Ключевое слово -- ОБЛАСТЬ ВИДИМОСТИ. GCC с вложенными функциями конечно позволяет выкрутится. А в общем случае -- либо глобальные переменные (которые сами по себе ещё то зло), либо указатели на структуру и жутко громоздкий и неэффективный код, либо таки громоздкие функции. Тем более, собственно серьёзных причин делать функцию короткой -- нет, если код писать грамотно и не увлекаться goto где не нужно (посмотрев на труды одного деятеля, я таки соглашаюсь с мыслью, что goto -- вреден, ибо граната в руках обезьяны), все современные компиляторы позволяют разграничить видимость внутри блоков (имеется ввиду { вот таких }).
Да, на счёт goto. Иногда таки полезен:
formatting link
-- "Иначе вариант с явными goto будет быстрее." -- и действительно существенно быстрее. Hу а классика жанра -- выход из нескольких вложенных циклов, альтернатива -- завернуть цикл в функцию, но опять же проблема области видимости, решаемая только в GCC.
[ZX]
K
Kirill Frolov
Sun Sep 13 2009 11:37, Andrey Arnold wrote to Nickita A Startcev:
AA> Даёшь, описание: "callback" - это очень просто!?
Я не понимаю смысла слова callback вообще. Под этим можно понимать что угодно. Корректно было бы, наверное, говорить об аргументах-функциях. Классический пример -- qsort тот же. В perl вместо функции можно блок кода подсунуть. По-сути это такое приближение к виртуальным функциям в C++, когда базовый класс вроде один, а методы в каждом конкретном случае свои. Где указателей нет, там и выкручиваются объектами унаследованными от, или там с интерфейсом такого-то типа...
[ZX]
K
Kirill Frolov
Sun Sep 13 2009 13:38, Nickita A Startcev wrote to Alex Mogilnikov:
В теории тип результата может быть динамический. Hа практике только как-то не вспоминается, переполнение везде вроде как просто проглатывается молча.
[ZX]
D
Dimmy Timchenko
Hello Andrey.
Sun Sep 13 2009 10:37, Andrey Arnold wrote to Nickita A Startcev:
KF> int16_t есть в ISO. Другое дело, что он, в общем-то скорей не нужен. KF> Из имеющихся там типов полезными с ходу признать могу только KF> int_fast*_t, int_least*_t и sig_atomic_t. Поддержка типов с конкретно KF> заданной шириной (например int16_t) -- большой вопрос конкретному KF> компилятору и CPU, и это скорей зло, нужное лишь в исключительных KF> случаях. Вообще C он содержит много возможности "прострелить себе KF> ногу", чем многие злоупотребляют, также и с самодельными типами.
Кстати, напомните плиз, а как эти типы выводить на печать и вводить с консоли? В смысле, что пихать в параметр для printf/scanf ( %i? %li? %lli? %llli?) или к какому из неизвестноширинных типов кастить?
. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... Шагающий авианосец
Mon Sep 14 2009 10:54, Nickita A Startcev wrote to Kirill Frolov:
NAS> static int counter; NAS> int get_counter(int); NAS> int set_counter(int); NAS> static int set_state(int); NAS> static .....
NAS> Кстати, что характерно, 'видимость в пределах файла' мало кем NAS> используется.
Hу не знаю. Я даже очень использую. Файл в таком случае -- это "объект" или "класс". Хотя скорей объект.
Хотя есть вот любители делать #include "*.c" или вовсе писать в 30 тыс. строк в одном файле. Оптимизация панимашь-ли. Это в лучшем случае...
K
Kirill Frolov
Mon Sep 14 2009 11:07, Nickita A Startcev wrote to Kirill Frolov:
KF>> В теории тип результата может быть динамический. Hа практике только KF>> как-то не вспоминается, переполнение везде вроде как просто KF>> проглатывается молча.
NAS> Почти везде. NAS> При делении на х86, если частное не лезет в регистр (например, делим NAS> int16(4096) на int8(4), ожидаем частное int8 ) то летит исключение.
Я про существующие языки программирования, а не про x86 или там пик. Hаличие динамической типизации от переполнения не спасает.