URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 42034
[ Назад ]

Исходное сообщение
"OpenNews: Открытый, расширяемый инструмент проверки правил кодирования может стать частью GCC."

Отправлено opennews , 29-Май-08 00:57 
Разработчики, задействованные в проекте GlobalGCC (http://www.ggcc.info/) представят на саммите разработчиков GCC 2008 открытый расширяемый инструмент автоматической проверки правил кодирования C++ для GCC и надеются что он войдет в основную ветку GCC и будет расширен и на остальные языки.
Проект особенно интересен тем что в отличие от известных коммерческих аналогов (Parasoft, Klocwork, Coverity), его можно адаптировать под собственные правила кодирования.


Модифицированный предоставленными патчами компилятор GCC строит по программе базу знаний в виде Пролог-утверждений и затем программа на Прологе производит валидацию стиля кодирования в соответствии с правилами.
В настоящий момент на Прологе реализована часть правил HICPP (High-Integrity C++), реализуются остальные правила стандарта правил кодирования и ведутся работы над созданием специализированного языка описания правил кодирования CRISP (Coding Rules In Sugared Prolog).

В ходе тестирования были проанализированы проекты...

URL: http://lwn.net/Articles/284112/
Новость: http://www.opennet.me/opennews/art.shtml?num=16153


Содержание

Сообщения в этом обсуждении
"Открытый, расширяемый инструмент проверки правил кодирования может стать частью GCC."
Отправлено Аноним , 29-Май-08 00:57 
Блин, крууть! Даже денег бы им дал чтобы продолжали это развивать...

"Открытый, расширяемый инструмент проверки правил кодирования..."
Отправлено Аноним , 29-Май-08 01:28 
>Блин, крууть! Даже денег бы им дал чтобы продолжали это развивать...

и в чём проблема ? http://www.ggcc.info/?q=contact :)


"Открытый, расширяемый инструмент проверки правил кодирования может стать частью GCC."
Отправлено MiG , 29-Май-08 01:23 
Вот если бы создали инструмент написания кода в хорошем стиле... :)

"Открытый, расширяемый инструмент проверки правил кодирования..."
Отправлено Аноним , 29-Май-08 02:50 
Use Python babe !:-)

"Открытый, расширяемый инструмент проверки правил кодирования..."
Отправлено MiG , 29-Май-08 19:24 
>Use Python babe !:-)

Python? А какое он имеет отношение к программированию? ;-)


"Открытый, расширяемый инструмент проверки правил кодирования..."
Отправлено vitek , 29-Май-08 12:34 
> Вот если бы создали инструмент написания кода в хорошем стиле... :)

таких программистов не бывает. :-)
это фантастика.


"Открытый, расширяемый инструмент проверки правил кодирования может ста"
Отправлено pavlinux , 29-Май-08 03:39 
> Тогда можно предположить о наличии в 345 строке файла foo.c возможности деления на ноль

Товарищ ZYX поясни... или дай посмотреть где это в оригинале!?


"Открытый, расширяемый инструмент проверки правил кодирования..."
Отправлено pavlinux , 29-Май-08 04:19 
                                                     Сам не выкуришь, другие отнимут.

---------------------------------

h(x, g(f())), x > 0

1. B функции h(x) имеется операция есть деление, и G возвражает 0, а она должна возвращать 0,
    иначе h(x) постоянно и независимо от других выдавала бы devide by zero,
    следственно там есть выражение N(x)/g(x), N(x) - это внутренние функции с участием x,
    положительность или отрицательность x тут пофиг, а если x/G - тем более.

2. Существуют выражения вида  N()/(x - g()) и N/(g(x) - x), при условии что |g()| = |x|


3. Далее, G бывает 0-ой, в трёх случаях:
     a) когда f() = g(), и внутри g() есть сложение, (напомню разность a - b = a + (-b) || -a + b )
     b) f() - так же возвращает 0, и тогда внутри G есть деление K()/f() = G
     c) и сама G постоянно 0-вая (но это бред и надо к доктору)
     В общем полная аналогия с предыдущей - h().

4. f() должна быть:

    a) f() = 0,
    b) f() = g()


У меня получился такой вывод, что функция g() просто лишняя, и её действия ни чего не меняют.


"Открытый, расширяемый инструмент проверки правил кодирования..."
Отправлено klalafuda , 30-Май-08 00:43 
>        Сам не выкуришь,
>другие отнимут.
>
>---------------------------------
>

ммм.. то, что под чёрточками - это программа юзкейса на прологе :-?

// wbr


"Открытый, расширяемый инструмент проверки правил кодирования..."
Отправлено pavlinux , 30-Май-08 01:04 
>ммм.. то, что под чёрточками - это программа юзкейса на прологе :-?

Да нет, МатАнал 1-й курс. :)


"Открытый, расширяемый инструмент проверки правил кодирования может стать частью GCC."
Отправлено Светочка , 29-Май-08 12:10 
Лучше бы навели порядок в исходниках gcc и перевели его с autotools на нормальную систему сборки, чтобы под windows нормально без бубна собирался.

"Открытый, расширяемый инструмент проверки правил кодирования..."
Отправлено vitek , 29-Май-08 13:20 
вот когда появиться продукт GNU/Windows, тогда и бубны отменят.
Столлман так сказал.

"Открытый, расширяемый инструмент проверки правил кодирования..."
Отправлено Аноним , 29-Май-08 13:22 
>Лучше бы навели порядок в исходниках gcc и перевели его с autotools
>на нормальную систему сборки, чтобы под windows нормально без бубна собирался.
>

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


"Открытый, расширяемый инструмент проверки правил кодирования..."
Отправлено Tred , 29-Май-08 13:40 
Windows == Posix?
Какога < х > разработчики должны напрягаться?


"Открытый, расширяемый инструмент проверки правил кодирования..."
Отправлено Kuraisu , 29-Май-08 14:52 
Если честно, на мой взгляд, autotools'ы - отличная система сборки. Очень гибкая и удобная. В своих проектах я использую именно её, и не вижу причин уходить от этого.
Она даже в освоении очень проста, нужно лишь попробовать. ;)

"Открытый, расширяемый инструмент проверки правил кодирования..."
Отправлено Светочка , 29-Май-08 20:20 
Autotools = MUST DIE!!! Они медленные, часто скрипт весит больше самой программы, ужасно работают под Windows (пусть у Windows много недостатков, но многие ей пользуются), при этом сама программа может не использовать платформенно-зависимые API и, соответственно, нормально работать и в Linux, и в Windows, но из-за automustdie компиляция программы под Windows может стать кошмаром. Чем не подходит cmake или scons в качестве замены - не знаю? Вполне нормальные современные системы сборки. Может быть их не используют из-за их объектно-ориентированности (ведь настоящие программы пишут только на C, bash и m4 :] )? Или из-за того, что какой-нибудь пользователь соберет их под так многими нелюбимом Windows? Как же так, то возможно бы он GNU/Linux поставил, а тут так и будет пользоваться проприетарщиной.

"Открытый, расширяемый инструмент проверки правил кодирования..."
Отправлено pavlinux , 29-Май-08 21:14 
У Светочки одна пробма - autotools в каждом коменте пишет. =)

"Открытый, расширяемый инструмент проверки правил кодирования..."
Отправлено vitek , 29-Май-08 22:35 
а мужики то клюют! :-)

"OpenNews: Открытый, расширяемый инструмент проверки правил к..."
Отправлено phpcoder , 29-Май-08 21:58 
Хорошая новость. Спасибо!



"OpenNews: Открытый, расширяемый инструмент проверки правил к..."
Отправлено eee , 29-Май-08 22:48 
На prolog кто-нибудь пишет?

"OpenNews: Открытый, расширяемый инструмент проверки правил к..."
Отправлено pavlinux , 30-Май-08 01:03 
>На prolog кто-нибудь пишет?

Ага, ядро Linux портируем на Visal Mono Sharp Prolog++ .NEту#