| 1.2, Анод (?), 23:41, 06/01/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
> Features
> JIT compile Lua scripts to native code using LLVM's JIT engine. JIT supports x86, x86_64, PowerPC 32/64 processors.
> Compile Lua scripts to native executables.
> Cross-compile Lua scripts to native executables/modules a different target then the host.
Торт!
| | |
| |
| 2.57, AnonuS (?), 01:57, 07/01/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
> ... Сгенерированный платформонезависимый псевдокод может
> быть преобразован при помощи JIT-компилятора в машинные инструкции
> непосредственно в момент выполнения программы. ...
[li]Псевдокод — язык описания алгоритмов, использующий ключевые слова языков программирования, но опускающий подробности и специфический синтаксис.
[li]Псевдокод — (в неформальной лексике) байт-код, машинно-независимый код низкого уровня, генерируемый компилятором и исполняемый виртуальной машиной.
Взято отсюда: http://ru.wikipedia.org/wiki/%D0%9F%D1%81%D0%B5
Доколе будет распространятся эта гнилая "неформальная лексика" ?
| | |
| |
| 3.85, Аноним (-), 04:31, 07/01/2014 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Доколе будет распространятся эта гнилая "неформальная лексика" ?
Почему вообще не использовать англоязычные термины, если только "русское" слово биткод не кажется более лучше. Например, в медицине/биологии используются термины на мертвом языке (латынь, если кто не понял) и никто в мире вроде не жалуется на непатриотичность, все всех понимают - универсальный язык. Почему в IT нельзя использовать универсальную терминологию на почти мертвом языке и не ломать голову. Помнится, одна страна уже вроде попыталась в патриотически-националистическом порыве перевести все на рiдну мову, было смешно.
| | |
| |
| |
| 5.110, Аноним (-), 16:26, 07/01/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Но свой комментарий ты всё-таки написал по русски?
Да вы тут все демагоги недоношенные.
| | |
|
| |
| 5.185, Аноним (-), 02:04, 09/01/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Таки IT будет там же, где на украине медицина, если всю терминологию перековеркать.
| | |
|
|
|
| |
| 3.111, Аноним (-), 16:27, 07/01/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Хреновый там JIT.
> Годный JIT у LuaJIT.
Ну, перепиши и прославишься.
| | |
| |
| |
| 5.189, arisu (ok), 02:21, 09/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Так зачем, LuaJIT уже есть.
так тому анонимусу же главное — «прославиться». поэтому он ничего и не пишет: на «приветмирах» не прославишься, а для сложных проектов нормально работающий мозг нужен.
| | |
|
|
|
| 2.187, arisu (ok), 02:20, 09/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Features
>> JIT compile Lua scripts to native code using LLVM's JIT engine. JIT supports x86, x86_64, PowerPC 32/64 processors.
>> Compile Lua scripts to native executables.
>> Cross-compile Lua scripts to native executables/modules a different target then the host.
> Торт!
это не торт, это куча мусора. чем оно лучше LuaJIT — тем, что надо весь монструозный llvm с собой таскать, да ещё и c++ компилятор, чтобы LLVM собрать? тьфу.
| | |
|
| 1.3, pavlinux (ok), 23:44, 06/01/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 > В Clang Static Analyzer существенно улучшена поддержка C++,
> сокращено число ложных срабатываний и расширено число выявляемых ошибок;
char *str_port;
char *str_p;
str_p = (char *) calloc(1, 5);
str_port = str_p; // Вот тут оно матерится, что "Value stored to 'str_port' is never read"
str_port = strpbrk(fulladdr, ":");
str_port++;
port = (uint16_t) strtol(str_port, NULL, 10);
free(str_p);
| | |
| |
| |
| |
| 4.7, Анод (?), 00:15, 07/01/2014 [^] [^^] [^^^] [ответить]
| +3 +/– |
Нет, ты в той строке присваиваешь значение, а в следующей затираешь его. Или я где-то не прав?
| | |
| |
| |
| Часть нити удалена модератором |
| 6.11, parad (ok), 00:40, 07/01/2014 [^] [^^] [^^^] [ответить]
| +5 +/– |
 > Value stored to 'str_port' is never read
попробуй еще раз перевести и с равни с тем о чем ты говоришь.
| | |
| |
| 7.14, ананим (?), 00:52, 07/01/2014 [^] [^^] [^^^] [ответить]
| –2 +/– |
Переменные могут быть неинициализированы.
Он бы ещё на это ругался:
int a, b=5;
a=b+1; // и писал бы — а потерялась, ай-ай-ай.
| | |
| |
| 8.26, parad (ok), 01:13, 07/01/2014 [^] [^^] [^^^] [ответить] | +4 +/– | ну ты тоже гугл транслейтом воспользовался написано же - запизанное значение н... текст свёрнут, показать | | |
|
|
|
| 5.12, ананим (?), 00:49, 07/01/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Не прав.
Неинициализированному указателю присваивается значение.
Это штатная ситуация. И таких много.
| | |
| |
| 6.15, Аноним (-), 00:55, 07/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
2 раза подряд присваиваем.
Где это она штатная? Я ещё понял бы двойное присваивание если одно присваивание выполнялось при условии каком-то(то есть тут было ветвление), а так бессмысленное действие.
| | |
| |
| 7.20, ананим (?), 01:05, 07/01/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Где два?
Вначале объявляем (значение при этом не определено). Потом присваиваем.
Вот если бы я не определённую переменную захотел использовать, вот тогда и матюгался.
Зыж
И не нужно свои стандарты какие-то выдумывать.
Полно подобного кода. Например пустой двусвязный список, 2-а указателя инизиализируются на самого себя. И т.д.
Я могу хоть 100500 указателей с одним и тем же значением понасоздавать.
А вот читать 100500 таких ложных срабатываний... так между ними что-то важное и пропустишь.
| | |
| |
| |
| |
| |
| |
| 12.63, pavlinux (ok), 02:32, 07/01/2014 [^] [^^] [^^^] [ответить] | –2 +/– | Так, мужики, мне нужна эта фича, чтоб сохранить адрес выделенной области Потому... большой текст свёрнут, показать | | |
| |
| 13.69, skb7 (ok), 03:03, 07/01/2014 [^] [^^] [^^^] [ответить] | +/– |  А что, разве clang анализатор ругается на этот код первый листинг Например g... текст свёрнут, показать | | |
| |
| |
| |
| 16.84, Inome (ok), 04:20, 07/01/2014 [^] [^^] [^^^] [ответить] | –1 +/– |  На самом деле эту переменную компилятор игнорирует, так как с ней не производитс... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 8.28, Аноним (-), 01:15, 07/01/2014 [^] [^^] [^^^] [ответить] | +/– | Полно подобного кода Например пустой двусвязный список, 2-а указателя инизиализ... текст свёрнут, показать | | |
| |
| |
| |
| |
| |
| 13.64, BayaN (ok), 02:33, 07/01/2014 [^] [^^] [^^^] [ответить] | +/– |  Вопрос в том, будет ли он ругаться в случае инициализации переменой или нет В п... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
|
|
| 2.9, xdbxd (?), 00:28, 07/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
LLVM всё правильно ругаецца. Нефиг 2 раза подряд ЗАПИСЫВАТЬ значение указателя.
| | |
| |
| 3.10, pavlinux (ok), 00:35, 07/01/2014 [^] [^^] [^^^] [ответить]
| –5 +/– | |
> LLVM всё правильно ругаецца. Нефиг 2 раза подряд ЗАПИСЫВАТЬ значение указателя.
Чо????
| | |
| |
| 4.13, Аноним (-), 00:51, 07/01/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
str_p = (char *) calloc(1, 5);
str_port = str_p; // Вот тут оно матерится, что "Value stored to 'str_port' is never read"
str_port = strpbrk(fulladdr, ":"); // ниразу не считав str_port мы его перезаписали
А что непонятно?
Сначала в str_port засунули 1 указатель, а потом нифига с ним не делая перезаписываем его. Получается что строка str_port = str_p; бессмысленна и её надо выкинуть или выполнять какие-то действия с указателем.
| | |
| |
| 5.16, ананим (?), 00:57, 07/01/2014 [^] [^^] [^^^] [ответить]
| –4 +/– |
В str_port ничего не запихивали, прикинь.
Он до этого имеет неопределённое значение.
И это наводит на мысль, что? Он бы не матюгнулся, если бы я его начал использовать?
Вот тогда было б хренова.
Павлуша, проверь что скажет, если эту строку закомментить, плс.
| | |
| |
| 6.18, pavlinux (ok), 01:01, 07/01/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> В str_port ничего не запихивали, прикинь.
Это указатель!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
4 (8) байт!!! ВСЁ, НЕТ ТАМ БОЛЬШЕ НИЧЕГО!
> Павлуша, проверь что скажет, если эту строку закомментить, плс.
Молчит, всё нормально.
| | |
| |
| 7.25, ананим (?), 01:11, 07/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> >В str_port ничего не запихивали, прикинь.
>Это указатель!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!4 (8) байт!!! ВСЁ, НЕТ ТАМ БОЛЬШЕ НИЧЕГО!>
Иииииииии? :D
>>Павлуша, проверь что скажет, если эту строку закомментить, плс.
>Молчит, всё нормально
Ну и слава Богу.
С рождеством.
| | |
| 7.33, ананим (?), 01:21, 07/01/2014 [^] [^^] [^^^] [ответить]
| +/– |
Зыж
А если и следующую?
До инкремента?
Будет увеличивать неинициализированный указатель?
| | |
| |
| |
| 9.79, ананим (?), 03:47, 07/01/2014 [^] [^^] [^^^] [ответить] | +/– | Вот не трынди, ок Переменная есть переменная У неё есть свой адрес, а вот что ... текст свёрнут, показать | | |
|
|
|
| 6.19, Аноним (-), 01:02, 07/01/2014 [^] [^^] [^^^] [ответить]
| +3 +/– |
Он ругается на эту строку потому что при следующем упоминании str_port мы затёрли значение, а то которое положили в этой строке ни разу не использовали, но ни как не потому что в этой строке мы затираем значение которое ни разу не использовали (про что вы подумали).
| | |
| |
| 7.21, pavlinux (ok), 01:06, 07/01/2014 [^] [^^] [^^^] [ответить]
| –4 +/– | |
> Он ругается на эту строку
Какая нафиг строка ЭТО УКАЗАТЕЛЬ! НЕТ в С строк.
| | |
| |
| |
| 9.104, ананим (?), 11:05, 07/01/2014 [^] [^^] [^^^] [ответить] | –1 +/– | Вот только согласно павлинуху он матюгается именно на первое присваивание, а не ... текст свёрнут, показать | | |
|
|
|
| 6.35, Inome (ok), 01:28, 07/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
str_port=адрес начала выделенного 5 байтового пространства. Он не должен на это ругаться
| | |
|
|
|
| 3.59, Славик (?), 02:02, 07/01/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Дело даже не в том что это указатель. Переменная может быть смаппирована на порт вывода например. Который может вообще не читаться.
| | |
|
| 2.56, Аноним (-), 01:54, 07/01/2014 [^] [^^] [^^^] [ответить]
| +4 +/– | |
Позорище-то какое. Павлуша, оказывается, не понимает указатели.
>str_port = str_p; // Вот тут оно матерится, что "Value stored to 'str_port' is never read"
>
>str_port = strpbrk(fulladdr, ":");
Смотри. В первой строчке кода ты кладёшь некое значение (вообще не важно в данном случае, указатель или просто int) в str_port, дальше это значение не читаешь из этой переменной, а сразу же, во второй строчке, записываешь новое значение в эту же переменную.
Первая строчка вообще бесполезна, и оно на неё ругается. В принципе оно могло бы и на обе строчки указать: здесь мол ты пишешь, а вот здесь опять туда же пишешь. Но решили, видимо, не перегружать сообщениями.
| | |
| |
| 3.61, AnonuS (?), 02:17, 07/01/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Позорище-то какое. Павлуша, оказывается, не понимает указатели. ...
Наверное просто переменные, к указателям данная ошибка наверное имеет таки косвенное отношение.
> Но решили, видимо, не перегружать сообщениями.
нашего Павлика.
| | |
| |
| 4.102, Аноним (-), 10:39, 07/01/2014 [^] [^^] [^^^] [ответить]
| +3 +/– |
Скорее всего Павлик автоматически в голове разыменовывает указатель и не понимает, что слово Value в сообщении анализатора означает сам указатель, а не строка, на которую он указывает.
| | |
| |
| 5.192, Аноним (-), 10:36, 09/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Скорее всего Павлик автоматически в голове разыменовывает указатель и не понимает, что
> слово Value в сообщении анализатора означает сам указатель, а не строка,
> на которую он указывает.
Дак естественно, что в контексте указателей анализатор имеет ввиду адрес, к-й этот указатель хранит. Это ж естественно, но Паша что-то не понимает.
| | |
|
|
|
| 2.86, Аноним (-), 04:51, 07/01/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
>char *str_port;
>char *str_p;
>str_p = (char *) calloc(1, 5);
>str_port = str_p; // Вот тут оно матерится, что "Value stored to 'str_port' is never read"
>str_port = strpbrk(fulladdr, ":");
И абсолютно правильно матерится. Не нравится - не заставляй умный анализатор проверять свое творчество.
А вообще лучше блоб нвидевский проверь анализатором и расскажи нам об успехах.
| | |
|
| 1.32, pavlinux (ok), 01:21, 07/01/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
А теперь я покажу, как спрятать от этой дуры "double free"
#include <stdlib.h>
int main(void)
{
char *a;
char *b;
b = (char *)calloc(1, 5);
a = b;
a++;
free(b);
free(a);
return 0;
}
$ scan-build gcc -Wall -Wextra -W test.c
scan-build: Removing directory '/tmp/scan-build-2014-01-07-43' because it contains no reports. // ДА ТЫ ЧО??!!!!
./a.out
*** glibc detected *** ./a.out: double free or corruption (fasttop): 0x0000000001573010 ***
======= Backtrace: =========
/usr/lib64/tls/x86_64/libc.so.6[0x3000878b66]
./a.out[0x4005c7]
/usr/lib64/tls/x86_64/libc.so.6(__libc_start_main+0xf5)[0x3000821455]
./a.out[0x4004a9]
======= Memory map: ========
00400000-00401000 r-xp 00000000 00:0f 606571 /tmp/a.out
00600000-00601000 r--p 00000000 00:0f 606571 /tmp/a.out
00601000-00602000 rw-p 00001000 00:0f 606571 /tmp/a.out
01573000-01594000 rw-p 00000000 00:00 0 [heap]
...
...
...
| | |
| |
| |
| 3.39, pavlinux (ok), 01:35, 07/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> А чё у тебя гцц, а не шланг?
шлаг это компылятор!
На, скушай
$ clang -W -Wall -Wextra test.c
$ echo $?
0
> Палишься? :D
Палишься, сыннко! :D
Я ваще-то про Шланг Static Analyzer
| | |
|
| 2.42, freehck (ok), 01:37, 07/01/2014 [^] [^^] [^^^] [ответить]
| –2 +/– |
 Да уж. Как говорил Бабаян, указатели - головная боль архитектуры современных компьютеров.
| | |
| |
| 3.46, Inome (ok), 01:42, 07/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
На ассемблере куда проще работать с адресами и указателями и это (факт!). Ждём патч для Си на преобразование указателей в более человеческую форму!11
| | |
| 3.51, ананим (?), 01:49, 07/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну… пока что(?) лучше с ними, чем без них.
Не, в С++ (особенно начиная с С++11) их применять вообще нет надобности. Но конструкции порой, скажем так, сложные получаются.
| | |
| 3.81, Crazy Alex (ok), 03:52, 07/01/2014 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Это головная боль Бабаяна, может? ну предельно примитивная же конструкция. Что может быть проще чем коробочка, в которой лежит номер другой коробочки?
| | |
| |
| 4.83, Inome (ok), 04:06, 07/01/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
Ага, "проще некуда" и прям совсем не заставляют задуматься конструкции типа этой: "(*(void(*)())0x8048330)((char *)10,(int *)0x8048341);" которые довольно-таки часто можно встретить в разных эксплойтах или в сорцах доисторических времен, этак 80х-90 годов, где если не через строчку, в каждом файле можно увидеть подобное:)
| | |
| |
| 5.91, skb7 (ok), 06:49, 07/01/2014 [^] [^^] [^^^] [ответить]
| +3 +/– | |
пффф...
typedef void (*func_t)();
#define FUNC_ADDR (func_t)0x8048330
#define ARG1 (char *)10
#define ARG2 (int *)0x8048341
int main(void)
{
func_t func = FUNC_ADDR;
func(ARG1, ARG2);
return 0;
}
и что тут сложного?
| | |
| |
| 6.92, skb7 (ok), 06:53, 07/01/2014 [^] [^^] [^^^] [ответить]
| +4 +/– |
Единственное, что там вообще может заставить задуматься, это первая звёздочка, которая там на самом деле и не нужна вовсе. Тут расписано:
http://stackoverflow.com/a/17321313
Единственное, что делает ту запись сложной, это намеренная обфускация кода. Ну так это в любом языке можно сделать, даже без указателей.
| | |
| 6.127, Inome (ok), 19:11, 07/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Никто не говорил, что это сложно. Ваша конструкция вообще читается с первого раза). Это заставляет задуматься и какое-то время потратить на разбор.
| | |
| |
| 7.139, skb7 (ok), 02:05, 08/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
заставляет, но я просто к тому, что не стоит выдавать обфусцированный код за проблемы указателе
| | |
| 7.140, skb7 (ok), 02:09, 08/01/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
Заставляет. Я имею ввиду, что не стоит выдавать обфусцированный код за проблемы указателей или проблемы Си (см. начало обсуждения). Можно писать и с использованием указателей так, что сразу всё будет понятно. И Си дает достаточно возможностей для написания выразительного кода. Просто в том примере код намеренно запутан.
| | |
|
|
| 5.123, metallica (ok), 17:51, 07/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Приведённый пример прост, вызов функции с параметрами указателями на char с значениями 10, и 0x804834, по указателю с значением 0x8048330 который есть указатель на функцию, принимающую и возвращающую void, есть гораздо сложнее.
| | |
| |
| 6.128, An123321 (?), 19:35, 07/01/2014 [^] [^^] [^^^] [ответить]
| +/– |
Пупок не развяжется ещё "сложнее" разбирать ? Линки на иоцц с сложными, добавлю себе в портфолио)
| | |
| |
| 7.166, metallica (ok), 11:40, 08/01/2014 [^] [^^] [^^^] [ответить]
| +/– |
Ну дык кто его знает каким компилятором думается компилить C или С++,
поэтому написал бы "(*(void(*)(char*,int*))0x8048330)((char *)10,(int *)0x8048341);"
Вопрос корректности записи оставался на совести автора, наше дело представить
её смысл.
| | |
| |
| 8.172, skb7 (ok), 19:46, 08/01/2014 [^] [^^] [^^^] [ответить] | +1 +/– | Естественно C Потому что на C приведенный пример не скомпилируется, т к в C ... большой текст свёрнут, показать | | |
|
|
|
|
|
| 3.88, AnonuS (?), 05:05, 07/01/2014 [^] [^^] [^^^] [ответить]
| +5 +/– | |
> Да уж. Как говорил Бабаян, указатели - головная боль архитектуры современных компьютеров.
Твой Бабаян - обычный неосилятор указателей !!!
:-)))
| | |
| |
| 4.114, Аноним (-), 16:29, 07/01/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> Да уж. Как говорил Бабаян, указатели - головная боль архитектуры современных компьютеров.
> Твой Бабаян - обычный неосилятор указателей !!!
> :-)))
И - да, он авторитетище!
| | |
|
|
| 2.76, skb7 (ok), 03:15, 07/01/2014 [^] [^^] [^^^] [ответить]
| +/– |
Странно, у меня всё ок. Проверяю ваш код вот так:
$ scan-build gcc -c main.c
scan-build: Using '/usr/bin/clang' for static analysis
main.c:10:9: warning: Attempt to free released memory
free(a);
^~~~~~~
1 warning generated.
scan-build: 1 bugs found.
scan-build: Run 'scan-view /tmp/scan-build-2014-01-07-011258-4567-1' to examine bug reports.
Версия clang:
$ aptitude -F %p search ~i^clang
clang-3.4
| | |
| 2.87, Аноним (-), 04:58, 07/01/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> А теперь я покажу, как спрятать от этой дуры "double free"
Лол, теперь ты обиделся на статический анализатор за то что он обнаруживает НЕ ВСЕ твои косяки? Это не удивительно, особенно если учесть что ты не умеешь его использовать.
| | |
| |
| 3.120, pavlinux (ok), 17:20, 07/01/2014 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> А теперь я покажу, как спрятать от этой дуры "double free"
> Лол, теперь ты обиделся на статический анализатор за то что он обнаруживает
> НЕ ВСЕ твои косяки? Это не удивительно, особенно если учесть что
> ты не умеешь его использовать.
ТЫ МУДИЛО АНОНИМНОЕ, ВЫСЕР ВАКУУМ ЭТО ВАЖНАЯ ИНФОРМАЦИЯ
| | |
|
|
| |
| 2.97, oOo (?), 08:41, 07/01/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> О, попробую снова собрать свою генточку сабжем. На 3.3 почти удалось.
А помните как линуксоеды тут и на лоре на фряшников собачилисть?
А терерб - наперегонки :)
| | |
| |
| 3.105, ананим (?), 11:14, 07/01/2014 [^] [^^] [^^^] [ответить]
| +/– |
Наперегонки что? Эксперементируют со своей системой?
На так у меня (на десктопе, не на серверах) половину пакетов интеловским компилятором собрано.
Вот только в линухе эти эксперементы по желанию, а в бсде добровольно-принудительно.
И уж тем более я не агитирую за самый кошерный компилятор, как некоторые. Просто гцц самый надёжный вариант во всех смыслах.
| | |
| |
| 4.106, Fracta1L (ok), 11:20, 07/01/2014 [^] [^^] [^^^] [ответить]
| +/– |
 Вот да, согласен.
У меня мотивом попыток собрать генту шлангом выступила быстрая сборка. На Firefox, например, разница была в 10 минут (емнип) в пользу clang. Однако далеко не все пакеты собираются цлангом, а некоторые даже если и собираются - работают весьма странно, пример - падающий компиз при попытке свернуть окно в заголовок.
| | |
| |
| 5.107, Аноним (-), 14:06, 07/01/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
На FreeBSD шлангом собираются уже почти все порты. Gentoo просто тормозит с импортом соответствующих патчей.
| | |
| |
| |
| 7.109, iZEN (ok), 15:28, 07/01/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
 over-24K портов FreeBSD отстают от портов Gentoo по разнообазию версий разве что, но не по уникальности.
| | |
| |
| |
| 9.136, Аноним (-), 00:15, 08/01/2014 [^] [^^] [^^^] [ответить] | +/– | Не в портах, но лежит прямо рядышком с ядром фряхи в виде модулей ядра фряхи, ве... большой текст свёрнут, показать | | |
| |
| 10.137, iZEN (ok), 01:07, 08/01/2014 [^] [^^] [^^^] [ответить] | –1 +/– | Зачем распаковывать вручную Есть порты gentoo http www freshports org search... текст свёрнут, показать | | |
|
|
| |
| 9.130, Аноним (-), 19:44, 07/01/2014 [^] [^^] [^^^] [ответить] | +1 +/– | В списке спонсоров гос учреждений нет В OpenBSD после того как Тео послал их в ... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 1.133, Yaisis (?), 23:01, 07/01/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Будущее за LLVM, я это давно уже понял.
И промежуточный байткод - это круто, так как можно компилировать в него программы, выполняя супероптимизацию и в таком виде можно распространять их, а конечную компиляцию в машинный код выполнять в момент установки под нужную архитектуру. Эта компиляция по-идее должна осуществляться намного быстрее, чем из исходников, написанных, например, на Си.
В .NET круто, что там общий набор библиотек и из любого языка можно использовать одни и те же функции. Я не понял пока, тут так же будет или нет ?
| | |
| |
| 2.134, Admiral (?), 23:51, 07/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Будущее за LLVM, я это давно уже понял.
> И промежуточный байткод - это круто, так как можно компилировать в него
> программы, выполняя супероптимизацию и в таком виде можно распространять их, а
> конечную компиляцию в машинный код выполнять в момент установки под нужную
> архитектуру. Эта компиляция по-идее должна осуществляться намного быстрее, чем из исходников,
> написанных, например, на Си.
Юзвери лают – караван идет.
> В .NET круто, что там общий набор библиотек и из любого языка
> можно использовать одни и те же функции. Я не понял пока,
> тут так же будет или нет ?
Если MS заинтересуют они будут пилить в гордном одиночистве, ибо винда в транке llvm ни кому не нужна
| | |
| |
| 3.141, Yaisis (?), 02:25, 08/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Юзвери лают – караван идет.
Вы хоть знаете, что такое LLVM и как она работает ?
> Если MS заинтересуют они будут пилить в гордном одиночистве, ибо винда в транке llvm ни кому не нужна
Причём тут MS ?
Никто вроде про винду и не вспоминал.
Про ихнюю .NET я вспомнил только потому, что какой бы язык в ней вы не использовали, базовый набор библиотек в нём один и тот же. Т.е. будь это C#, F# или Pyton например они могут использовать набор функций фреймворка. И поэтому нет необходимости при изучении нового языка изучать и его библиотеки.
| | |
| |
| 4.175, Crazy Alex (ok), 21:36, 08/01/2014 [^] [^^] [^^^] [ответить]
| +/– |
В результате базовый набор ограничений тоже оказывается для всех одним и тем же. В общем, минусы тоже есть, хотя плюсы велики, да. Под никсами, впрочем, сишный аби обычно вполне достаточен.
| | |
|
|
| 2.135, metallica (ok), 23:58, 07/01/2014 [^] [^^] [^^^] [ответить]
| +3 +/– |
Хомячкам из норки не видно каким убожеством является их божество .NET,
потому-что ничего больше не знают, а знали бы, даже не упоминали бы
его, не говоря о выражении мнения о каком-то его удобстве и превосходстве.
| | |
| |
| 3.142, Yaisis (?), 02:59, 08/01/2014 [^] [^^] [^^^] [ответить] | +/– | Безразницы, кто написал NET и то, что её больше используют под виндовс NET - ... большой текст свёрнут, показать | | |
| |
| 4.143, metallica (ok), 03:14, 08/01/2014 [^] [^^] [^^^] [ответить]
| +/– |
Как Вас колбасит от проблемы разного названия функций в разных библах. По
мне так reference в зубы и вперёд.
Не спасёт Вас LLVM потому-что в мире опенсурса тут же начнут появляться
альтернативы, форки и т.д. Это как ситуация с C++ STL и boost-
всё, что есть в STL продублировали в boost, и обязательно с некоторыми труднозапоминаемыми изменениями
в семантике и сигнатурах. Обязательно, стань LLVM стандартом, начнут появляться разные
LLVM++ и всюду начнут пропихиваться, потому-что это верный способ для
программеров показать свою деятельность и выделить именно свой проект.
| | |
| |
| 5.149, Yaisis (?), 04:16, 08/01/2014 [^] [^^] [^^^] [ответить] | +/– | Сомниваюсь, что форк LLVM появится, но если появится, то ничего страшного Пусть... большой текст свёрнут, показать | | |
| |
| 6.163, Аноним (-), 10:40, 08/01/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Сомниваюсь, что форк LLVM появится, но если появится, то ничего страшного.
Не появится по одной простой причине - developers, developers, developers (c) Ballmer
Не найдется столько разработчиков компиляторов, чтобы его тянуть.
| | |
|
|
| |
| 5.151, Yaisis (?), 04:41, 08/01/2014 [^] [^^] [^^^] [ответить] | +/– | NET создали, как конкурента Яве, но Макрософт реализовала его только под виндов... большой текст свёрнут, показать | | |
|
| 4.145, ананим (?), 03:27, 08/01/2014 [^] [^^] [^^^] [ответить] | +2 +/– | Попахивает матёрым маркетинговым булшитом и промытыми мозгами Ничего они оттуда... большой текст свёрнут, показать | | |
| |
| 5.146, ананим (?), 03:47, 08/01/2014 [^] [^^] [^^^] [ответить] | +2 +/– | ззыж Чтобы не быть голословным, пруфы 1 http en wikipedia org wiki Register_... большой текст свёрнут, показать | | |
| 5.147, Yaisis (?), 04:03, 08/01/2014 [^] [^^] [^^^] [ответить] | –1 +/– | Я и не говорю, что берут, но LLVM начали делать позднее NET и его разработчики ... большой текст свёрнут, показать | | |
| |
| 6.150, ананим (?), 04:28, 08/01/2014 [^] [^^] [^^^] [ответить]
| +3 +/– | |
>Сам байткод не является полноценным и независимым и он только для одного языка. В LLVM байткод - это полноценная самодостаточная виртуальная машина
Так, свободны молодой человек. :D
Полный бред несёте. Очевидно, что вы были (надеюсь, что были), мягко говоря, не в курсе.
И теперь просто не желаете признавать свои ошибки. В силу воспитания и юношеского максимализма.
man intermediate representation (IR) (хотя, впрочем, предвидя это, пруфы я выше уже дал https://www.opennet.ru/openforum/vsluhforumID3/93448.html#146 которые вы не успели прочитать и сразу ринулись в «бой» :D)
Ещё раз. LLVM интересен не по-этому. Разберитесь с этой аббревиатурой. Как впрочем и с gcc.
| | |
| |
| 7.153, Yaisis (?), 05:16, 08/01/2014 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Полный бред несёте. Очевидно, что вы были (надеюсь, что были), мягко говоря, не в курсе.
И теперь просто не желаете признавать свои ошибки
Нет, я просто был не в курсе или просто подзабыл.
А недостатки GCC описаны тут http://rus-linux.net/MyLDP/BOOKS/Architecture-Open-Source-Applications/Vol-1/
Возможно в GCC какие-то уже устранили, он же развивается, но я не в курсе.
Ну а ваш предыдущий комментарий, похоже был позже моего написан, конечно бы я его учёл, если б увидел.
| | |
| |
| |
| 9.157, Yaisis (?), 06:24, 08/01/2014 [^] [^^] [^^^] [ответить] | –1 +/– | И по поводу LLVM я не знаю, что выйдет из него, но после понятия основных механ... большой текст свёрнут, показать | | |
| |
| |
| 11.171, Yaisis (?), 19:27, 08/01/2014 [^] [^^] [^^^] [ответить] | –1 +/– | gt оверквотинг удален GCC поддерживает множество систем предварительной обраб... большой текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 4.148, ананим (?), 04:15, 08/01/2014 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>т.е. если сейчас считается С/С++ одним из самых быстрых языков, благодаря своему оптимизатору
А ЭТОМУ где вас научили?
С/С++ быстры, потому что ГОРАЗДО ближе к низко-уровнему языку — ассемблеру.
Чтобы понятней — конструкции С/С++ преобразуются в гораздо меньший по объёму машинный код, чем большинство остальных высоко-уровневых языков. И это только для компилируемых языков!!!
И второй плюс — программист на С/С++ гораздо в большей степени владеет информацией в какой именно машинный код трансформируется та или иная конструкция.
>И так же хотелось бы, чтоб можно было без труда использовать в любом из языков любую внешнюю функцию, написанную тоже на любом языке, как в .NET можно написать функцию на C# и использовать её в F#.
То, что вас «научили» из любого языка относительно легко создавать и вызывать COM-объекты, ещё не значит, что все остальные языки разучились создавать и вызывать библиотеки (.a, .so,…)
Или вы о том, что там всё однообразно, хоть и безобразно, вызывается (другими одна на всё библиотека классов)? :D
| | |
| |
| 5.152, Yaisis (?), 05:04, 08/01/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> То, что вас «научили» из любого языка относительно легко создавать и вызывать COM-объекты, ещё не значит, что все остальные языки разучились создавать и вызывать библиотеки (.a, .so,…)
Нет, просто хотелось бы, чтобы установил например QT и его функции можно было вызывать в любых других языках. Сейчас надо самому описание внешних функций делать. Если это унифицировать и сделать регистрацию установленных компонентов, то ничего делать самому не надо будет.
Приведу пример: Я хочу установить QT, после чего сразу же в Си заработает следующий код:
#include <QApplication> ...
И я так же хочу, чтобы сразу же заработал следующий код на питоне:
import QApplication ...
И аналогичный код на других языках.
Но такого не будет, потому что для питона, например, надо установить PyQT(или что-то подобное, не помню уже), что является прослойкой(если не ошибаюсь), связывающей данный язык с библиотеками QT.
Не будет работать сразу потому, что нет стандарта и нет связи между разными языками и LLVM могла бы обеспечить такой стандарт и такую связь.
Приведу другой пример: Допустим я установил под .NET фреймворк OpenTK. То тогда я могу вызывать функции данного фреймворка, как из С++, С#, F#, Python и любого другого .NET языка.
COM-объект - это совсем другое, не то об чём я.
И кстати мне интересно, какая в Линуксе технология, заменяющая COM ?
| | |
| |
| 6.156, ананим (?), 06:06, 08/01/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>Нет, просто хотелось бы, чтобы установил например QT и его функции можно было вызывать в любых других языках.
Для этого есть биндинги (т.е. поддержка в самих языках). Например для Qt:
$ eix qt|grep -i bindi
* dev-libs/libindicate-qt
Description: Python bindings for the Qt toolkit
Description: A python binding for libpoppler-qt4
Description: Ruby bindings for Qt4
Description: Qt Perl bindings
Description: Qt Ruby bindings
…
И то, это для C++-библиотек (там имена в объектниках «коверкаются». подробности http://en.wikipedia.org/wiki/Name_mangling)
Для библиотек С (или при использовании extern "C" в С++, что требуется для dll в винде) всё ГОРАЗДО проще.
А вообще, это не технический, а административный вопрос стандартизации юзер-спейсного АПИ. И всё. Конечно, строем ходить проще, никаких проблем с пробками и транспортными коллапсами.
Но свобода творчества мне лично дороже. :D
| | |
| |
| 7.158, Yaisis (?), 06:45, 08/01/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Спасибо за разъяснение, но вот по-моему эти биндинги ни к чему, я как раз за построение общего универсального АПИ между языками. Мы же можем из любого языка вызвать Си функцию, но для этого её надо объявить определённым способом (extern(C) или что-то подобное) и надо указать, где находится библиотека и т.д.
А можно сделать и по-другому, если все установленные библиотеки будут регистрироваться, где-нибудь, а все языки будут видеть это дерево библиотек и сами с вызываемыми функциями связываться правильно, чтобы программист не делал лишних действий.(это просто пример, возможно не правильный)
А в LLVM такую связь теоретически можно сделать через байткод. Да и при написании нового языка там используются специальные функции LLVM для облегчения написания последнего(конечно можно и без них обойтись и написать всё полностью вручную). Вполне можно добавить в LLVM например функцию, которая будет возвращать список доступных библиотек(возможно такое уже есть, я не знаю), ведь конечную компиляцию и линковку всё равно будет осуществлять LLVM(у которой нет разницы между языками), а не сам язык. Так если все библиотеки в конечном счёте имеют вид байткода, у которого свой стандарт на всё и на вызываемые функции тоже, то какая разница, из какого языка этот байткод будет вызван ? Почему не предоставить всем языкам LLVM список экспортируемых функций другими языками ? Вообщем я не всё знаю об LLVM и не знаю, как это сейчас там работает.
| | |
| |
| 8.165, Аноним (-), 11:07, 08/01/2014 [^] [^^] [^^^] [ответить] | +2 +/– | LLVM тут ничем не поможет, так как компилятор любого языка должен видеть определ... текст свёрнут, показать | | |
| |
| 9.168, Yaisis (?), 18:57, 08/01/2014 [^] [^^] [^^^] [ответить] | –1 +/– | Дело в том, что у LLVM есть фреймворк для создания компиляторов, разработкики им... текст свёрнут, показать | | |
| |
| 10.188, Аноним (-), 02:21, 09/01/2014 [^] [^^] [^^^] [ответить] | +/– | Ты не понимаешь, определение вызываемой функции нужно на уровне исходников, текс... большой текст свёрнут, показать | | |
|
| 9.169, Yaisis (?), 19:01, 08/01/2014 [^] [^^] [^^^] [ответить] | –1 +/– | А компиляция вызова происходить будет на уровне байткода В LLVM компиляторы язы... текст свёрнут, показать | | |
|
|
|
| 6.159, ананим (?), 06:51, 08/01/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
>COM-объект - это совсем другое, не то об чём я.
>И кстати мне интересно, какая в Линуксе технология, заменяющая COM?
Во первых очень даже при чём. Это просто продолжение этой технологии.
На второй вопрос ответить сложнее. И вот почему — слишком большой круг задач, к которым эту технологию приспособили.
Но в оригинале COM-объект (тот что только с интерфейсом IUnknown) нужен только для одного — вызывать чужые блобы из своего ПО. Всё.
Опенсорс — это слишком креативно для корпорастов мс.
Если рассматривать далее, то пожалуйте в технологии IPC и RPC.
Кстати, COM ничем не отличается в этом плане. Просто позаимствовала RPC (со своими изменениями) вот отсюда — http://ru.wikipedia.org/wiki/%D0%A3%D0%B4%D0%B0 (и далее на DCOM), которую тоже можно использовать в своём ПО в linux (man rpcclient и даже http://www.bettina-attack.de/jonny/view.php/projects/php-msrpc/ ).
А вообще на текущий момент — dbus пожалуй стандарт (который теперь уже не демон, а в ядре. Спорное решение на мой взгляд, но вам понравится — теперь уж точно стандарт :D)
http://ru.wikipedia.org/wiki/Dbus (обратите внимание на вызовы методов. Там же ссылка на lor, где есть примеры) — как видите, писать можно на чём угодно и взаимодействовать с чем угодно.
| | |
| 6.193, Led (ok), 14:17, 09/01/2014 [^] [^^] [^^^] [ответить]
| +/– |
 > Приведу пример: Я хочу установить QT, после чего сразу же в Си
> заработает следующий код:
Какое отношение QuickTime имеет к Си-коду, школота?
| | |
|
|
| 4.174, ffirefox (?), 20:34, 08/01/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Проблема с .Net не то, что все языки на .Net будут одинаково быстро работать, а в том, что они будут одинаково тормозить. Но, как Вы правильно заметили, будут работать практически все и сразу (хотя, порой, исключения есть). С QT и традиционными компилируемыми языками код быстро будет работать гарантированно на одном языке (на котором писался), а вот для подключения библиотеки к другому языку приходится потрудится (хотя, не все так страшно, например, для того же Python или Lua). Но, потрудившись и скорость получим соответствующую.
| | |
|
|
|
| |
| 2.176, Аноним (-), 22:05, 08/01/2014 [^] [^^] [^^^] [ответить]
| +/– |
Разработчики Delphi и Lazarus забыли об этом тебя спросить и присобачили pascal к llvm.
| | |
| |
| 3.198, Владимир (??), 11:56, 10/01/2014 [^] [^^] [^^^] [ответить]
| +/– |
 llvm-pascal давно загнулся и не дышит.
Нет работающего транслятора pascal в llvm.
| | |
|
|
| 1.203, Аноним (-), 21:52, 13/01/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Ребят, может кто подскажет, каким образом реализовать замыкания с помощью llvm?
| | |
| 1.204, Perain (?), 22:37, 27/01/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
https://github.com/llvm-mirror/clang/commit/e0e019f
Profile-Guided Optimization (PGO) support is landing within LLVM's Clang C/C++ compiler in catching up to feature parity with GCC and their never-ending effort to improve performance of compiled binaries.
For those not normally excited by compilers, Profile-Guided Optimizations are a means of profiling a compiled program so that on subsequent compilations the compiler can better optimize the code for improved run-time performance. PGO is very different from traditional source-level optimizations and it's taken some time for Clang to implement the support besides the fact not many utilize this compiler optimization technique due to it being time intensive with requiring multiple compilations plus run-time profiling.
With a code commit that hit Clang mainline last week, there's now the initial instrumentation for Profile Guided Optimizations. While the code is still in early form, proper Clang PGO support will hopefully be a feature of LLVM 3.5.
| | |
|
