А вы не хотели бы сделать как один из ваших конкурентов (кажется Coverity): выложить ошибки опенсорсных проектов чтобы разработчики могли их поправить. Я после ваших предыдущих постов искал отдельную ссылку ошибок по Boost, но не нашел :(
А как ваша программа справится с более сложным кодом, например с Boost? Может ли она находить ошибки/странности при использования шаблонов. К примеру что-то типа #8702:
template<typename T>
class has_size_type
{
typedef char no_type;
struct yes_type { char dummy[2]; };
template<typename C>
static yes_type test(BOOST_DEDUCED_TYPENAME C::size_type x);
template<typename C, typename Arg>
static no_type test(Arg x); // Ошибка здесь. Должен быть '...' вместо шаблонного параметра
/*утилита может выдать предупреждение о том, что "ищется строгое соответствие с int. Вы имели в виду "..."?"*/
public:
static const bool value = sizeof(test<T>(0)) == sizeof(yes_type);
};
В таком случае извиняюсь за скепсис и желаю МЦСТ успехов с выходом на розничный рынок.
По поводу их програмных продуктов вы случаем ничего не знаете? Есть ли возможность получить их компилятор С++ и проверить его работу на других SPARC процессорах?
Заинтересовал меня вопрос с нашими компьютерами Эльбрус. Было несколько новостей, что производитель просил поддержки государства, что вещь готовая к применению и уже налажен выпуск и продажи, производитель работает на рынке черт знает сколько лет…
Решил купить, пособирать проекты на спаркоподобных процессорах…
Итог: в продаже нет, производитель на почту не отвечает, никто не знает где оно продается. Что не мешает производителю клянчить денег у государства.
В связи с этим фраза «Также сейчас МЦСТ допиливает Эльбрус под производство на Микроне.» вызывает легкое ощущение недоверия к статье…
Можете пожайлуйста дать ссылку на этот материал (с++11 совместимые строки). Интересно почтитать, что будет нового в следующей версии, а changelog GCC-4.9 молчит по поводу libstdc++.
Чтобы не быть голословным, приведу ссылки: Здесь указывается, что все регистры после системного вызова/прерывания(int 0x80) сохраняют свое значение (кроме EAX). Здесь утверждается, что вызов функции обязан восстановить занчения большинства регистров.
Таким образом, без разницы, встроится (за-inline-ится) pthread_* функция полностью, частично, или не встоится вообще, значения регистров она должна восстановить и компилятор может применять оптимизиции ориентируясь на это. Другими словами вызов внешней функции не гарантирует то, что текущий поток увидит измененное значение переменной _finish.
Теперь давайте заглянем в тело pthread_mutex_lock Даже заглядывать не будем, просто посмотрим на POSIX и увидим что некоторые функции pthread обязаны использовать memory barrier.
Любая атомарная операция является полным барьером (full memory barrier). Помнится в старых версиях ядра Linux использовалась атомарная инструкция прибавления 0 к одному из регистров в качестве memory barrier. Практически во всех pthread_* используются атомарные операции, следовательно после вызова pthread_* все модификации переменной _finishдолжны быть видны текущему потоку.
В этом Google C++ Style Guide пункт про размер бинарника идёт четвёртым из пяти аргументов против
noexcept так же служит и документацией к функциям (пункт второй из Google C++ Style Guide), так что уже соотношение пунктов «за» и «против» не 5:5 а где-то 5:3
эксепшены и весь сопутствующий механизм ориентированы на минимизацию оверхеда в случае, когда они не бросаются
— 100% верно для C++03, отчасти верно для C++11 в котором есть rvalue references (деструктивное копирование) и в котором уже алгоритмы подстраиваются в зависимости от спецификаторов исключений. См. «Ускорение работы стандартных алгоритмов»
В boost постарались решить путаницу, введя макросы BOOST_NOEXCEPT, BOOST_NOEXCEPT_IF(предикат)
BOOST_NOEXCEPT_EXPR(выражение).
Если их использовать, приведенный выше пример быдет выглядеть так:
template <class A>
void swap (A& a, A& b) BOOST_NOEXCEPT_IF(BOOST_NOEXCEPT_EXPR(A::operator=))
{
A tmp = a;
a = b;
b = tmp;
}
Выглядит чуточку понятнее (и немного более громоздко).
Если решите использовать оператор noexcept, стоит отметить, что компилятор GCC 4.7 достаточно часто падает с Internal Compiler Error при использовании сложных выражений.
Вы не могли бы мне скинуть полный отчет по ошибкам в личку (в буст рассылке нет письма об ошибках :( )? Постараемся исправить их до следующего релиза.
Ощутил. Внушает.
А вы не хотели бы сделать как один из ваших конкурентов (кажется Coverity): выложить ошибки опенсорсных проектов чтобы разработчики могли их поправить. Я после ваших предыдущих постов искал отдельную ссылку ошибок по Boost, но не нашел :(
По поводу их програмных продуктов вы случаем ничего не знаете? Есть ли возможность получить их компилятор С++ и проверить его работу на других SPARC процессорах?
Решил купить, пособирать проекты на спаркоподобных процессорах…
Итог: в продаже нет, производитель на почту не отвечает, никто не знает где оно продается. Что не мешает производителю клянчить денег у государства.
В связи с этим фраза «Также сейчас МЦСТ допиливает Эльбрус под производство на Микроне.» вызывает легкое ощущение недоверия к статье…
usingдля типов данных сильно непривычно.** За Azul VEGA спасибо, почитал, узнал много интересного.
Здесь указывается, что все регистры после системного вызова/прерывания(int 0x80) сохраняют свое значение (кроме EAX).
Здесь утверждается, что вызов функции обязан восстановить занчения большинства регистров.
Таким образом, без разницы, встроится (за-inline-ится) pthread_* функция полностью, частично, или не встоится вообще, значения регистров она должна восстановить и компилятор может применять оптимизиции ориентируясь на это. Другими словами вызов внешней функции не гарантирует то, что текущий поток увидит измененное значение переменной
_finish.Теперь давайте заглянем в тело pthread_mutex_lockДаже заглядывать не будем, просто посмотрим на POSIX и увидим что некоторые функции pthread обязаны использовать memory barrier._finishдолжны быть видны текущему потоку.— 100% верно для C++03, отчасти верно для C++11 в котором есть rvalue references (деструктивное копирование) и в котором уже алгоритмы подстраиваются в зависимости от спецификаторов исключений. См. «Ускорение работы стандартных алгоритмов»
BOOST_NOEXCEPT_EXPR(выражение).
Если их использовать, приведенный выше пример быдет выглядеть так:
Выглядит чуточку понятнее (и немного более громоздко).
Если решите использовать оператор noexcept, стоит отметить, что компилятор GCC 4.7 достаточно часто падает с Internal Compiler Error при использовании сложных выражений.