Рубрика «clang» - 5

в 12:46, , рубрики: c++, clang, cppcon, gcc, godbolt, x86_64, ассемблер, Компиляторы, отладка, Программирование

Продолжение цикла обзорных статей с конференции CppCon 2017.

Содержание цикла

На этот раз очень интересное выступление от автора Compiler Explorer (godbolt.org). Обязательно читать всем, кто для быстроты умножает на 2 с помощью сдвига (по крайней мере, на x86-64). Если вы знакомы с ассемблером x86-64, то можете перемотать до разделов с примерами ("Умножение", "Деление" и т.д). Далее слова автора. Мои комментарии в квадратных скобках курсивом.

Моя цель сделать так, чтобы вы не боялись ассемблер, это полезная вещь. И использовали его. Не обязательно все время. И я не говорю, что вы должны все бросить и учить ассемблер. Но вы должны уметь просмотреть результат работы компилятора. И когда вы это сделаете, то оцените, как много работы проделал компилятор, и какой он умный.

Читать полностью »

в 12:59, , рубрики: C, c++, clang, freebsd, gcc, pvs-studio, Блог компании PVS-Studio, информационная безопасность, Компиляторы, ошибки в коде, ошибки программистов, Си, статический анализ кода

Правим потенциальные уязвимости
Мы решили в меру своих сил регулярно искать и устранять потенциальные уязвимости и баги в различных проектах. Можно назвать это помощью open-source проектам. Можно — разновидностью рекламы или тестированием анализатора. Еще вариант — очередной способ привлечения внимания к вопросам качества и надёжности кода. На самом деле, не важно название, просто нам нравится это делать. Назовём это необычным хобби. Давайте посмотрим, что интересного было обнаружено в коде различных проектов на этой неделе. Мы нашли время сделать исправления и предлагаем вам ознакомиться с ними.
Читать полностью »

в 1:54, , рубрики: AST, c++, clang, clang-c, LLVM, компилятор, Компиляторы

Однажды, сидя вечером перед компьютером и предаваясь меланхолии и мыслям о бренности всего сущего, я задумчиво набрал в поиске одного крупного сайта по поиску работы аббревиатуру «LLVM», не надеясь, впрочем, увидеть там что-то особенное, и стал просматривать небогатый, прямо скажем, улов.
Как и следовало ожидать, почти ничего особенного не нашлось, однако одно объявление меня заинтересовало. В нём были такие строки:
«Кого мы возьмем «не глядя» или уровень выполняемых задач:
Вы скачали любой open source проект, собираемый при помощи gcc (объем исходного кода более 10 мегабайт) и для самого большого файла cpp смогли построить AST дерево при помощи clang с –fsyntax-only;
Вы скачали любой open source проект, собираемый при помощи Visual C++ (объем исходного кода более 10 мегабайт) и для самого большого файла cpp смогли построить AST дерево при помощи clang с –fsyntax-only;
Вы смогли написать утилиту, которая выделит все места деклараций и использования локальных переменных, а также все функции, не определенные в данном файле»

Ну что же, подумал я, какое-никакое, а развлечение на вечер.

Как приручить дракона. Краткий пример на clang-c - 1
Читать полностью »

в 13:28, , рубрики: c/c++, c++, clang, LLVM, open source, pvs-studio, PVS-Studio for Linux, static code analysis, Блог компании PVS-Studio, инструменты разработчика, информационная безопасность, Компиляторы, обзор кода, ошибки в коде, ошибки в программе, Разработка под Linux, статический анализ кода

PVS-Studio vs LLVMОколо двух месяцев назад я написал статью о проверке компилятора GCC с помощью анализатора PVS-Studio. Идея статьи была следующая: предупреждения GCC — это хорошо, но недостаточно. Надо использовать специализированные инструменты анализа кода, например, PVS-Studio. В качестве подтверждения я показал ошибки, которые PVS-Studio смог найти в коде GCC. Ряд читателей заметили, что качество кода GCC и его диагностики так себе, в то время как компилятор Clang современен, качественен, свеж и молод. В общем Clang — это ого-го! Что ж, значит пришло время мне проверить с помощью PVS-Studio проект LLVM.
Читать полностью »

в 5:21, , рубрики: C, c++, clang, const, gcc, компилятор, Компиляторы, оптимизация

Сегодня на /r/C_Programming задали вопрос о влиянии const в C на оптимизацию. Я много раз слышал варианты этого вопроса в течении последних двадцати лет. Лично я обвиняю во всём именование const.

Читать полностью »

в 14:17, , рубрики: C, c++, clang, gcc, linux, pvs-studio, PVS-Studio for Linux, PVS-Studio для Linux, Блог компании PVS-Studio, Разработка под Linux, Си, статический анализ кода, статический анализатор кода

PVS-Studio признаётся в любви к LinuxЭто заметка о любви. О любви статического анализатора кода PVS-Studio к замечательной открытой операционной системе Linux. Эта любовь молода, трогательная и ранима. Этой любви нужно помочь укрепиться. Вы поможете, если заранее запишитесь в добровольцы для тестирования beta-версии PVS-Studio for Linux.
Читать полностью »

в 9:24, , рубрики: c++, clang, Анализ и проектирование систем, Блог компании Инфопульс Украина, отладка, параллельное программирование

Писать многопоточные приложения нелегко. Некоторые средства статического анализа кода позволяют помочь разработчикам, давая возможность чётко определить политики поведения потоков и обеспечить автоматическую проверку выполнения этих политик. Благодаря этому появляется возможность отлавливать состояния гонки потоков или их взаимной блокировки. Эта статья описывает инструмент анализа потокобезопасности С++ кода, встроенный в компилятор Clang. Его можно включить с помощью опции командной строки −Wthread−safety. Данный подход широко распространён в компании Google — полученные от его применения преимущества привели к повсеместному добровольному использованию данной технологии различными командами. Вопреки популярному мнению, необходимость в дополнительных аннотациях кода не стала бременем, а наоборот, дала свои плоды выражающиеся в упрощении поддержки и развития кода.

Предисловие

Писать многопоточные приложения нелегко, поскольку разработчикам приходится представлять себе все многочисленные варианты взаимодействия потоков и использования ими ресурсов. Опыт показывает, что программистам не помешал бы для этого некоторый инструментарий. Многие библиотеки и фреймворки налагают на программиста некоторые требования по потокобезопасности при их использовании, однако далеко не всегда эти требования чётко указаны. И даже в тех случаях, когда всё хорошо задокументировано — это всего лишь выраженная в тексте документации просьба, а не строгая автоматическая проверка.

Средства статического анализа кода помогают разработчикам определить политики потокобезопасности и проверять их при сборке проекта. Примером таких политик могут быть утверждения «мьютекс mu всегда должен использоваться при доступе к переменной accountBalance» или «метод draw() должен вызываться только из GUI-потока». Формальное определение политик даёт два основных преимущества:

  1. Компилятор может показывать предупреждения в случае обнаружения нарушений политик. Нахождение ошибки на этапе компиляции значительно дешевле, чем отладка упавших юнит-тестов или, что ещё хуже, появление «плавающих» багов в продакшн-коде.
  2. Явно выраженные в коде спецификации потокобезопасности играют роль документации. Подобная документация очень важна для библиотек и SDK, поскольку программистам нужно знать, как их корректно использовать. Данную информацию, конечно, можно поместить в комментарии, однако практика показывает, что подобные комментарии имеют свойство устаревать, поскольку при обновлении кода они не всегда меняются синхронно.

Данная статья рассказывает о применении данного подхода в Clang, хотя изначально он был разработан для GCC, однако версия для GCC более не поддерживается. В Clang данная возможность реализована как предупреждение компилятора. В Google на данный момент вся кодовая база C++ компилируется с включенным по умолчанию анализом потокобезопасности.
Читать полностью »

в 5:02, , рубрики: C, cisc, clang, RISC, superscalr stack processor, Анализ и проектирование систем, архитектура, кодогенерация, Компиляторы, компиляция, масштабируемость, Параллелизм, стек, стековые машины, суперскаляр

Суперскалярный стековый процессор: оптимизация - 1
Продолжение серии статей, разбирающих идею суперскалярного процессора с
OoO и фронтендом стековой машины. Тема данной статьи — оптимизация обращений к памяти.

Предыдущие статьи:
1 — описание работы на линейном куске
2 — вызов функций, сохраняем регистры
3 — вызов функций, взгляд изнутри
Читать полностью »

в 17:36, , рубрики: c++, clang, game development, mac os x, SFML, xcode, документация, Локализация продуктов, перевод, Программирование, установка

SFML и Xcode (Mac OS X) - 1

От переводчика: данная статья является четвертой в цикле переводов официального руководства по библиотеке SFML. Прошлую статью можно найти тут. Данный цикл статей ставит своей целью предоставить людям, не знающим язык оригинала, возможность ознакомится с этой библиотекой. SFML — это простая и кроссплатформенная мультимедиа библиотека. SFML обеспечивает простой интерфейс для разработки игр и прочих мультимедийных приложений. Оригинал статьи можно найти тут. Начнем.
Читать полностью »

в 16:44, , рубрики: clang, ios development, objective-c, os x development, разработка под iOS, Разработка под OS X

Пришла мне как-то в голову идея, а можно ли взять блок и отдать для target-action?
Есть готовые решения, как к примеру BlocksKit и другие библиотеки, однако их решение заключается в сохранении блока, установкой таргета и вызова блока из указанного селектора.

Зачем тогда нужна эта статья?

Я захотел создать способ генерации селектора, по которому будет вызван блок. Что здесь сложного, скажете вы? imp_implementationWithBlock + class_addMethod и дело закрыто. Но при этом подходе есть одно серьезное требование, это первый аргумент блока — владелец метода.

Как обойти это требование и сделать такое?

    [button addTarget:self action:[self ax_lambda:^(UIButton *sender, UIEvent *event){
        NSLog(@"click on button %@, event = %@", sender, event);
    }] forControlEvents:UIControlEventTouchUpInside];

    [button addTarget:self action:[self ax_lambda:^{
        NSLog(@"click");
    }] forControlEvents:UIControlEventTouchUpInside];

Или даже вот так

    __block NSInteger sum = 0;
    [self performSelector:[self ax_lambda:^(NSNumber *argA, NSNumber *argB) {
        sum = [argA integerValue] + [argB integerValue];
    }] withObject:@(2) withObject:@(3)];
    //sum — 5

    SEL selSum = [self ax_lambda:^NSInteger(NSInteger argA, NSInteger argB){
        return argA + argB;
    }];
    NSInteger(*funcSum)(id, SEL, NSInteger, NSInteger) = (NSInteger(*)(id, SEL, NSInteger, NSInteger))objc_msgSend;
    NSInteger sum2 = funcSum(self, selSum, 2, 3);
    //sum2 — 5

Реализация оказалась настолько интересной, что я решил написать об этом.
Читать полностью »

1...456...8
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js