Должен ли я использовать функции С++ 0x сейчас?

С официальным выпуском VS 2010, безопасно ли мне начать использовать частично реализованную функцию С++ 0x в моем новом коде?

Функции, которые меня интересуют прямо сейчас, реализованы VС++ 2010 и последними версиями GCC. Это единственные два, которые я должен поддерживать.

В терминах "безопасности", упомянутых в первом предложении: могу ли я начать использовать эти функции (например, лямбда-функции) и по-прежнему гарантировать, что мой код будет скомпилирован через 10 лет на компиляторе, который надлежащим образом соответствует С++ 0x, когда он официально выпущен?

Я предполагаю, что я спрашиваю, есть ли вероятность того, что VС++ 2010 или GCC закончится как VС++ 6; он был выпущен до того, как язык был официально стандартизирован и, следовательно, разрешил компрометировать очень плохо сформированный код.

В конце концов, Microsoft говорит, что "10 - это новый 6".;)

Ответ 1

Есть несколько элементов, которые я уже обнаружил, которые не записываются в стандарт. Например, это не сработало бы:



struct test {
  int operator()(int);
};

std::cout << typeid( std::result_of<test(int)>::type ).name() << std::endl;

Согласно сайту wikipedia на С++ 0x, он должен. По-видимому, VS2010 использует определение TR1 result_of, которое отличается от того, что будет иметь С++ 0x (на основе decltype).

Кроме того, это не работает:



std::bind<int>([](int i)->int {return i; });

Он терпит неудачу, потому что вызов std:: result_of (ну, его реализация) завершается с ошибкой, потому что тип лямбда не имеет результата typedef. Это, конечно, то, почему вы возвращаете тип возврата к вызову привязки, но, по-видимому, он почему-то игнорирует его и продолжает искать самостоятельно. Повышенная версия bind работает, как ожидалось. По этой причине мы продолжаем использовать ускоренную версию bind в нашем проекте.

Кроме того, если вы отметите в http://blogs.msdn.com/vcblog/archive/2010/04/06/c-0x-core-language-features-in-vc10-the-table.aspx?CommentPosted=true#commentmessage, что некоторые изменения еще не реализованы VS2010, которые будут влиять на лямбда-выражения. Я не смог их сломать, но тогда я не использовал вложенные лямбды и, вероятно, никогда не буду.

Вы также должны помнить, что boost:: shared_ptr и std:: shared_ptr несовместимы. Не удивительно, но вы должны это знать, если собираетесь использовать тот или иной... Я бы рекомендовал не и то и другое, и мы просто будем придерживаться стимула.

В VS2010 также нет никакого объявления. Достаточно легко сделать:


template < typename T > T&& declval();

Пример использования:


template < typename T >
struct point
{
  T x,y;
};

template < typename T1, typename T2 >
point<decltype(declval<T1>() + declval<T2>())> operator + (point<T1> const& lh, point<T2> const& rh)
{
 ...
}

Вы также заметите на странице, с которой я связан выше, что я уже обсуждал с членами команды разработчиков (или частью PR или что-то еще), что есть ошибка в decltype. Там больше, чем тот, о котором я упоминаю, поэтому я покажу оба:


template < typename T1, typename T2 >
auto operator + (point<T1> const& lh, point<T2> const& rh)
  -> point<decltype(lh.x + rh.x)>
{
...
}
point<int> x; point<double> y;
point<double> pt = x + y; // fails, operator + returned point<const double>

void f();
auto ptr = &f;

std::cout << typeid( decltype(*ptr) ).name() << std::endl;
std::cout << typeid( decltype(*&f) ).name() << std::endl; // should output the same thing...outputs void (*)()

Также... согласно некоторым обменам электронной почты о decltype и result_of, это должно работать:



std::result_of< decltype(f)() >::type x = f();

С моей домашней версией std:: result_of, которая использует decltype, это будет работать, если выражение decltype (f)() работает правильно. Это не. Дает некоторую ошибку в функции, возвращающей функцию. Вы должны использовать "decltype (& f)()", чтобы заставить выражение работать.

Итак, конечно... мы используем его. Там есть некоторые ошибки и дерьмо. Преимущества перевешивают ожидание ИМХО. Не ожидайте, что ваш код станет стандартным, когда выйдет стандарт, и будущие компиляторы MS могут его нарушить.

Ответ 2

Набор функций С++ 0X довольно исправлен, поэтому я бы сказал, для этого. Окончательный проект предложения должен быть выполненным в августе согласно wikipedia.

В любом случае многое из того, что можно получить от boost (на самом деле, много 0X вещей исходит от повышения) - см. повысить TR1. Вы можете повторно использовать эти функции путем повышения, даже если компилятор не полностью С++ 0X.

Ответ 3

Значительная часть важных вещей (то есть вещей, которые вы обычно часто используете) в значительной степени ставятся в камень. Я думаю, что риск написания кода, который становится нестандартным, крайне низок, особенно если вы придерживаетесь подмножества спецификации, реализованной в текущих компиляторах.

Для хорошей таблицы перечисления поддержки функций перейдите здесь. Лично auto переменные, ссылки r-value и lambdas - это в значительной степени большие возможности для использования и хорошо поддерживаются.

Ответ 4

Я предполагаю, что я спрашиваю, есть ли вероятность того, что VС++ 2010 или GCC закончится как VС++ 6; он был выпущен до того, как язык был официально стандартизирован и, следовательно, разрешил компрометировать очень плохо сформированный код.

Можно случиться, но очень маловероятно, ИМХО. Не только MS, но и другие производители компиляторов уже поддерживают некоторые функции С++ 0x, и я ожидаю, что Standard Committee будет предельно осторожен в отношении нарушения совместимости на данный момент.

Ответ 5

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

Ответ 6

Если вы ожидаете, что ваш код будет оставаться нетронутым в течение многих лет и хотите, чтобы он выжил с изменениями компилятора без вмешательства, я бы посоветовал вам придерживаться С++ 98/03.

Однако большинство кодов поддерживается со временем, поэтому я не думаю, что это такое важное соображение. Я бы рекомендовал использовать то, что делает ваш код лучше, и планировать некоторую работу при обновлении компиляторов.